abapGit – Elevate Your SAP ABAP Development Game


Managing code within the SAP ecosystem can be quite complex. The introduction of abapGit brings new ways to how version control and collaboration in ABAP development may be handled. This blog aims to provide an overview of abapGit, its features and use cases within SAP development. By understanding and leveraging abapGit, you can streamline your development processes and enhance overall project efficiency.


What is Git?

Every software developer sooner or later stumbles upon Git and its most popular platform GitHub, which is s a cloud-based code repository. The idea is that each developer works within a decentral local copy of the software project, represented by a collection of text files.

Every change (“commit”) will be uploaded (“push”) to the Git Server (“repository) to share.

Other developers may download the changes (“pull”) to synchronize the latest status.

An additional version (“branch”) of the repository can be created at any time, to have a separate coding environment. By doing so, a developer can work on a new experimental feature, while the main project remains unaffected and safe. Once the changes are satisfying, the “feature branch” can be “merged” back into the “master branch”, combining the new features with the existing code.

The repository not only stores the source code itself, but also meta data with information about each change. This allows powerful version control and the ability to easily revert to any previous state.

It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg.
— Jack William Bell

What is abapGit?

abapGit is an open-source Git client developed in ABAP for ABAP version 7.02+. It is a tool to import and export code between ABAP systems and thereby integrates the robust version control features of Git directly into the SAP landscape.

All popular cloud-based Git platforms are supported, the most famous being GitHub and GitLab. There is also an integrated abapGitServer, which runs just locally on your ABAP instance. And you may use an offline repository, if you want to work with your local storage only.

Not all object types are supported, but the list is quite long and still growing: https://docs.abapgit.org/user-guide/reference/supported.html

Different flavors are available:

Community abapGit

This original version has been maintained by the abapGit community since 2014. It’s still an active project and receives regular enhancements. You can get it here: https://abapgit.org

SAP abapGit

In 2018 SAP started to contribute to the project and at the same time natively integrated abapGit into the SAP Cloud Platform ABAP Environment. The documentation is available here: https://help.sap.com/docs/btp/sap-business-technology-platform/working-with-abapgit.


Stands for Git-enabled Change and Transport Management System and is an enhancement of the well-known CTS. gCTS emerged in parallel with SAP’s abapGit development efforts. It’s not directly related but can be considered its successor project. gCTS is available for on-premise S/4HANA 2019+ and for the SAP Cloud Platform ABAP Environment. You can find more information here: https://help.sap.com/docs/ABAP_PLATFORM_NEW/4a368c163b08418890a406d413933ba7/f319b168e87e42149e25e13c08d002b9.html

 SAP vs. Non-SAP Development

In ABAP, all developers work in one common environment:

Classic ABAP Development, Source: DSAG

This all-in-one environment has its benefits, but there are also disadvantages and shortcomings regarding version control:

  • Objects locks prevent parallel development in same source
  • Handling is inconsistent and it’s not available for all object types
  • No simple undo mechanism as temporary versions are deleted
  • Limited tracking abilities
    • What changed since last transport?
    • Which changes were done in a class or function group?
    • How did the code base look one month ago?
    • Who did changes in a certain package?

On the other hand, in most programming languages the developers work locally and in parallel with other developers. Changes are regularly committed, tested and merged and here Git and other integrated third-party tools like Crucible (Code Review) and Jenkins (Continuous Integration / Delivery) are de facto standard.

Development in Non-SAP Landscapes, Source: DSAG

With Git there is a comprehensive versioning system in place:

  • Detailed traceability with lots of filtering and sorting options
  • Backups and capability to return to any point in time
  • Riskless experiments in separate branch
  • Code comments, discussions and reviews
  • DevOps methodology (integration and automation of development and IT operations)

How to integrate abapGit in your landscape?

There are multiple possibilities how to integrate Git into an ABAP landscape but there is no real answer which way is the best, since every customer is unique. In any case Git is not a replacement of CTS but can be seen as an enhancement to it. Let’s have a look at two example scenarios:

abapGit for Improved Version Control

The following architecture is very similar to classic ABAP development, meaning that every developer works on the same DEV system. However, abapGit has been integrated and enables code versioning and reviews, but also code exchange with other systems or open-source projects.

ABAP Development with abapGit, Source: DSAG

This architecture is easy to setup, but it does not overcome the lack of parallel development. That’s because a) in an SAP system there is only one active version of code and b) abapGit works on package level and only one branch may be checked out at a time. This means that developer 1 can work on feature 1, but developer 2 can’t work on feature 2 if it’s in the same package on the same system.

abapGit for Parallelization and Deployment

The next architecture follows a different approach. Here the developers do not work on the same DEV system anymore, but each one has an own dedicated ABAP environment e.g. via Docker or VM. abapGit has been integrated as central code repository, so each code change goes through Git and only after code review it is pulled into the main DEV system.

ABAP Development with abapGit and branches, Source: DSAG

This architecture leverages the full potential of abapGit, which means that branching and parallel development becomes possible. However, the effort and costs are very high, since lots of individual SAP systems must be provided and maintained. And another downside is that not all object types are supported in abapGit. Therefore, unsupported objects would still need to be developed directly in the main DEV system, which kind of contradicts the centralization and parallelization approach.

Use Cases – Why Should You Use abapGit?

As just explained in the two integration scenarios, abapGit has its limits but there are still lots of useful ways to benefit from it:

Streamlined Version Control

Have your code synchronized with abapGit to benefit from enhanced versioning. Together with GitHub or similar platforms you can use it for code discussions, reviews or rollbacks.

Open-Source Offerings

You can use abapGit to share your open-source code and demos, by simply synchronizing it on GitHub. And at the same time, you can easily bring in third-party open-source code into your own system and experiment with it.

Account Transfer

With abapGit, you can export your ABAP objects from any system to another, typically from on-premise to cloud or from one cloud system to another. You are thereby independent of transport routes or different system releases.

Code Transfer

You can utilize abapGit to export your code assets from your development landscape and import them into your customers‘ system. That may be quite useful for proof-of-concepts or integration tests.

Backup and Archiving

Storing ABAP code outside of the SAP system can be a great benefit. It may help to prevent code loss e.g. when the system had to be restored from an old backup in an emergency. Or it might come in handy for exporting your legacy coding e.g. when a system is decommissioned.

Global Code Reuse

If you use common utilities across multiple ABAP systems or have a parallel sandbox, you probably want to keep it all in sync. Doing manual code updates on each system or maintaining transport routes just for that purpose might be troublesome. With abapGit the synchronization is easy and quickly done.

How to Set-up?

Here is a step-by-step guide for the initial set-up:


GitHub is the most popular Git platform, so most people probably want to use this as their repository.

  • Go to https://github.com and create your personal account
  • Create a new repository and in the process make sure that the README.md will be automatically added. That’s important because there must be at least one file for the access to work.
  • Generate a personal access token via Settings -> Developer Settings -> Personal access tokens.
  • Please note: you can access GitHub through your browser via your user name and password. But for access with abapGit you cannot use your password but instead you’ll need that access token.

SSL Certificate

The communication between abapGit and GitHub will be secure. Following preparations are required:

  • In your browser go to http://github.com, export the SSL certificate and save it locally
  • In your browser go to http://api.github.com, and also export and save the SSL certificate
  • In your ABAP instance, execute transaction STRUST, switch to change mode and double click on the folder “SSL client SSL (Client Anonymous)”
  • Go to menu Certificate -> Import and choose the github.com certificate file, which you previously exported. Click on button “Add to Certificate List” and afterwards button Save.
  • Repeat those steps for the api.github.com certificate as well.


Now you’ll finally need to get the tool itself:

  • Go to https://abapgit.org and click on “Latest build”
  • You’ll see a huge ABAP report, which you need to download (right click -> save-as)
  • In transaction SE38 create the new report ZABAPGIT_STANDALONE
  • Go to menu Utilities -> More Utilities -> Upload/Download -> Upload and select the saved file
  • Activate and execute the report
  • Click on „New Online“
  • Enter your Github URL and the ABAP package you want to synchronize it with
  • Click „Create Online Repo“
  • That’s it, happy pulling and staging 😊

Summary and Conclusion

In general, Git aims to improve developer collaboration and productivity, and that’s probably something that every ABAP project can use more of.

The concept of branches and parallelized development may be strange for an ABAP developer, who has only ever known SAP systems that have just one active code version at a time. But nonetheless, there’s a desire to strive for DevOps processes to better service the business users.

SAP designed the development and deployment process in a quite robust way, but there are certain shortcomings in terms of collaboration and version control. abapGit can help to improve development processes and at the same time it enables new interesting capabilities and use cases for your ABAP landscape.

This article also briefly mentioned gCTS, which has similar goals as abapGit. It plays a vital role in SAP’s aim to support continuous integration. If you want to learn more about it, please have a look here: https://support.sap.com/content/dam/support/en_us/library/ssp/tools/Software-logistic-tools/Ideas_CI_ABAP_V3.pdf