Lesson 2 of 6
abapGit essentials: flavors, setup and your first push
9 min
Listen to this lesson
abapGit turns ABAP objects into files and back. Pushing serializes objects from the system into files in a git repository; pulling deserializes files back into objects. Everything else in this lesson follows from that.
Pick the right flavor
| Flavor | Where it runs | How you use it | Support |
|---|---|---|---|
| Community standalone version | Any system on SAP_BASIS 702 or higher (on premise, private edition) | One large report, ZABAPGIT_STANDALONE, run in SE38 | Community (GitHub issues); SAP doesn't support it |
| Community developer version | Same | Full set of objects, transaction ZABAPGIT; needed to contribute; supports parallel processing | Community |
| SAP version (SAP-owned fork) | SAP BTP ABAP environment and SAP S/4HANA Cloud Public Edition | ADT plug-in with the abapGit Repositories and abapGit Staging views | SAP standard support |
abapGit flavors as documented by the abapGit project and SAP Help Portal (checked October 2026).
Contoso runs SAP S/4HANA Cloud Private Edition, so the SAP-shipped version isn't available there; Kenji's team would use the community version. SAP's own setup page tells you to check with your system administrator before installing it, and the abapGit docs say it is typically used in development systems only. At Contoso that means Sam (Basis) and Nadia (security) approve the installation, and it goes into CMD only, never CMQ or CMP.
Install and connect (community version)
- Download the latest standalone build, create report
ZABAPGIT_STANDALONE(in a local package such as$ABAPGIT), upload the code and activate it. Don't name it ZABAPGIT if you might install the developer version later. - Set up SSL so the system can reach the git server (the docs have SSL setup and SSL test pages). If the system can't reach the server, use offline repositories with ZIP import and export instead.
- Choose New Online, enter the repository URL and a package. The docs recommend a new SAP package for each repository and warn against packages that already contain other objects.
- For a package that already exists, initialize the remote repository with a README so it isn't empty, create the online repository, then Stage, Add All and Commit and Commit.
On SAP's cloud systems, the flow is the same idea through ADT: install the abapGit Repositories plug-in from the update site SAP documents, open the abapGit Repositories view, link a package to the repository URL and branch, and stage changes in the abapGit Staging view.
Online, offline and authentication
An online repository talks to the git server directly over HTTPS; abapGit shows a pull link when the remote has moved ahead and marks changed objects in the status column. An offline repository works with ZIP files: you export a ZIP of the package or import one, and you move the ZIP yourself. Offline is useful when a development system has no route to the git server, or for a one-off copy of code between systems, but it gives up the shared history that makes review possible. For agent work, use online repositories.
Authentication to the git server is per developer. Use personal access tokens with the narrowest scope your server offers, never a shared team account, so that each push in the server's log maps to a named person. That matters later, in the audit trail of sap-aid-302: the person who pushed an agent's change is the person who vouched for it.
What lands in the repository
abapGit stores .abapgit.xml in the repository root. It holds settings for everyone: the main language, the starting folder (usually /src/) and the folder logic. Each object becomes at least one file named object name.object type.extension, for example zbp_r_cmc_coreagreement.clas.abap for code and zbp_r_cmc_coreagreement.clas.xml for metadata. Classes and function groups are split into several files, which keeps diffs small and readable.
| Folder logic | Rule | Use when |
|---|---|---|
| Prefix | Subpackage names must start with the parent package name | You may install into a different parent package, even a local $ package |
| Full | Any package name; folders carry full package names | Packages must have the same names in every system |
| Mixed | A combination, described in the repository settings docs | You inherit an existing structure that needs it |
Folder logic is stored in .abapgit.xml and decides how packages map to folders.
The commit page needs three fields: a comment, the committer's name and the committer's e-mail. An author can differ from the committer. At Contoso, agent changes are committed with the developer as committer and the comment starts with the transport number, so the git history and the CTS history point at each other.
What would you do?
A developer suggests linking the existing package ZCMC_TOOLS, which holds 40 utility objects from several teams, to the new core agreement repository as well, "so we only have one repository to watch". The core agreement objects live in ZCMC_CORE_AGREEMENT. What should Kenji decide?
- The community version (standalone or developer) runs on SAP_BASIS 702+ and isn't supported by SAP; the SAP-owned fork runs in the BTP ABAP environment and S/4HANA Cloud Public Edition with ADT plug-in views.
- Install the community version in development systems only, with Basis and security approval.
- One package tree per repository; .abapgit.xml holds main language, starting folder and folder logic.
- Commit with a meaningful comment that includes the transport number.
Check your understanding · not graded
Lesson check
1. Contoso runs SAP S/4HANA Cloud Private Edition. Which abapGit flavor can Kenji's team use in CMD?
2. Which file in an abapGit repository stores the main language, starting folder and folder logic?
3. What does folder logic Prefix require?
4. Which fields are mandatory on the abapGit commit page?