Lesson 1 of 6
Why git for ABAP now
9 min
Listen to this lesson
On a Tuesday morning in CMD, Contoso's development system, a coding agent working for Kenji's ABAP team changed fourteen objects in the core agreement app: two behavior pool methods, a CDS view, an access control, a message class and nine test methods. Every change was recorded in a transport task, as always. Then Luis, Contoso's release manager, asked a simple question before the request moved to CMQ: what exactly changed, and who looked at it? The transport object list answered the first half only roughly. It named fourteen objects. It didn't show the lines.
This course is about closing that gap. When people write ABAP, the classic tools are usually enough, because the author can explain the change. When an agent writes ABAP, nobody remembers writing the code, so the change has to explain itself. Git gives you that: one diff for the whole change, a place for reviewers to comment, an approval that is recorded, and a history you can search later. This lesson explains what ABAP already records, what git adds, and why the difference matters more once agents are involved.
What the ABAP stack already gives you
- Change and Transport System (CTS). Every repository change is recorded in a task under a change request. The request is the unit that moves from development to quality to production.
- Version management. The system keeps versions of an object, and you can compare two versions of one object in ADT or the ABAP Workbench.
- One active version. SAP's gCTS documentation puts it plainly: only one active version of an object exists in the system. Objects are locked while a request is open, so two developers can't change the same object in parallel.
- Quality checks. The ABAP Test Cockpit (ATC) and ABAP Unit can run before release, and ATC can be set to check requests at release.
What the stack doesn't give you is a review record across objects. Comparing versions object by object is slow, and nothing records that a second person read the change and agreed with it. Many teams fill the gap with a code review spreadsheet or a ticket comment. That works until volume rises.
| Question a reviewer asks | Classic CTS and version management | Git with pull requests |
|---|---|---|
| Which objects changed? | Object list of the request | Files in the commit or pull request |
| Which lines changed? | Version compare, one object at a time | One diff across every changed file |
| Who reviewed it? | Not recorded by the tool | Reviewer and approval stored with the pull request |
| What was discussed? | Outside the tool (mail, tickets) | Comments attached to the exact lines |
| Can checks run automatically? | ATC at release, if configured | Pipelines triggered by the push or pull request |
| What moves the code to production? | The transport request | Still the transport request in a classic landscape (see lesson 6) |
Why agents raise the stakes
Coding agents change four things about the review problem. They produce more change per hour than a person, so reviewers see larger change sets. Their output is plausible: it compiles, reads well and often passes the tests the agent wrote itself, which makes shallow reviews feel safe. They are non-deterministic, so the same prompt can produce a different change tomorrow, and you can't re-derive the code from the instruction. And they act through tools, so a mistake can touch objects nobody asked about. Each of these pushes you toward the same control: a complete, minimal diff that a human reads and approves before the change moves on.
SAP itself points in this direction. The MCP tools that ship with the ABAP Development Tools (ADT) MCP server include abap_transport_get_unified_diff, which generates a unified diff for all objects in a transport request. A diff is now a first-class artifact in SAP's own agentic tooling. Git adds what a one-off diff lacks: history, discussion and a recorded approval.
Two tools, not one
Two git integrations exist for ABAP, and the rest of this course treats them separately because they are not interchangeable.
- abapGit is an open-source git client written in ABAP. The community version runs on SAP_BASIS 702 and higher and is supported by its community, not by SAP. SAP also ships its own version (a fork it supports) in the SAP BTP ABAP environment and SAP S/4HANA Cloud Public Edition, used through an ADT plug-in. In the latest Help Portal pages, the ABAP environment is listed under the SAP Business AI Platform name.
- gCTS, the Git-enabled Change and Transport System, is part of the ABAP platform (SAP S/4HANA 1909 and later on premise). It stores ABAP development and Customizing objects in git repositories and can update target systems by pulling commits.
SAP's troubleshooting notes for gCTS state that gCTS and abapGit use different file formats and are not interoperable, and that using both on the same repository isn't supported. Pick one per repository.
What would you do?
Back to Tuesday: Luis won't release the fourteen-object request to CMQ until he knows what changed and who looked at it. Kenji has no git repository for the core agreement package yet. What is the best answer for this request, today?
- CTS records which objects move; it doesn't record a cross-object diff or a reviewer's approval.
- Agents produce more, plausible, non-repeatable change through tools, so a complete diff with a recorded approval becomes the key control.
- SAP's ADT MCP tools include a unified diff of a transport request, which shows diffs are now part of SAP's own agentic workflow.
- abapGit (community or SAP-shipped) and gCTS are separate tools with different file formats; pick one per repository.
Check your understanding · not graded
Lesson check
1. What does SAP's gCTS documentation say about versions of an ABAP object in one system?
2. What does a pull request add that the transport object list does not?
3. Which ADT MCP tool shows that SAP treats diffs as part of agentic ABAP work?
4. Can one git repository be shared between abapGit and gCTS?