abapGit: Version Control for ABAP Teams and How to Build a Real CI/CD Pipeline

For most of SAP’s history, version control in ABAP development meant the transport system: objects moved from DEV to QAS to PRD via transport requests, and the “version history” was a comparison of successive transport imports. There was no diff, no branch, no pull request, and no way to run automated checks before a change reached the quality system.

abapGit changed that. It is not a workaround or a niche community experiment — it is the de facto standard for ABAP source control, used by SAP’s own development teams and thousands of customer organisations. This post explains how it works technically, how to structure branching for ABAP teams with realistic transport workflows, how to wire it into CI/CD, and how s4ready.ai uses abapGit repositories as the foundation for automated readiness scanning.

Why ABAP needed a different approach to version control

Standard version control tools (Git, SVN) operate on files. ABAP source lives in a relational database — SAP’s own repository — managed by the Workbench. An ABAP class is not a file; it is a set of rows in tables like SEOCLASSI, SEOCLAASDF (include sources), and associated metadata tables. There is no .abap file to commit.

abapGit bridges this gap through serialisation: it converts an ABAP package’s objects from their repository representation into a set of files (.abap source, .xml metadata) that Git can manage. Deserialisation reverses the process — pulling files from Git and importing them back into a SAP system’s repository.

The serialisation format is deterministic: the same object in two systems with the same content produces identical files, which means diff output is meaningful and merge conflicts are real conflicts in the ABAP source.

How abapGit works technically

Serialisation

Each ABAP object type has a serialiser class in abapGit that knows how to extract and reconstruct it. For a class ZCL_MY_CLASS:

• ZCL_MY_CLASS.clas.abap — the class pool source
• ZCL_MY_CLASS.clas.testclasses.abap — local test classes
• ZCL_MY_CLASS.clas.xml — metadata (class properties, attributes, method signatures not in source)

For a CDS view ZI_MY_VIEW:

• ZI_MY_VIEW.ddls.asddls — the CDS source
• ZI_MY_VIEW.ddls.xml — metadata

The .xml files capture object properties that have no natural representation in the source text — activation status, package assignment, transport layer, object description. They are not optional: deserialising without them loses metadata.

Transport integration

abapGit operates alongside the SAP transport system, not in place of it. When you pull changes into a development system via abapGit, the changed objects still need to be collected into a transport request and moved to QAS/PRD through the standard CTS landscape. abapGit handles source synchronisation between systems; transports handle the promoted move through the landscape.

This is not a limitation — it is the correct architecture. The transport system enforces the landscape topology and release governance that most regulated SAP environments require. abapGit adds the Git layer on top: source truth lives in Git, but objects still travel through the transport chain.

Branching strategies for ABAP teams

The challenge

Classic Git branching strategies (Gitflow, trunk-based) were designed for codebases where the development environment is local — each developer has their own runtime. In ABAP, the development system is shared. If two developers check out different feature branches from Git into the same DEV client, they are working in the same SAP repository and will interfere.

The practical solutions are:

1. Package-based branch isolation

Assign distinct ABAP packages to distinct features, with strict package-to-branch mapping. Developer A works on ZFEATURE_PAYMENTS package on branch feature/payments; Developer B works on ZFEATURE_REPORTING on branch feature/reporting. There is no object overlap, so shared-system conflicts do not arise.

This works well when features have clear package boundaries. It breaks down for cross-cutting changes to shared utility packages.

2. Multiple development clients

Some organisations run multiple DEV clients (DEV1, DEV2) within the same DEV system, each mapped to a different feature branch. abapGit pulls to the appropriate client; transports are created per client. More infrastructure overhead, but genuine branch isolation.

3. Trunk-based development with feature toggles

For teams with disciplined practices: everyone works on main/trunk in the same DEV client, but unreleased features are hidden behind custom feature flags (a custom table, a BAdI switch, or a configuration entry). All code is always integration-tested; incomplete features are present but inactive. This is operationally simpler and scales well for CI/CD.

For most enterprise SAP teams, a combination of approach 1 (package isolation) for large independent features and approach 3 (trunk-based with flags) for smaller changes is practical.

CI/CD pipeline with abapGit

flowchart TD
    DEV[Developer — ABAP Workbench / ADT]
    AG[abapGit — pull/push in SAP system]
    GH[GitHub / GitLab repository]
    PR[Pull Request]
    CI[CI Runner — GitHub Actions / Jenkins]
    AL[abaplint — static analysis]
    ATC_CI[ATC via abap-openapi-client — if cloud system available]
    SCAN[s4ready A1 Scan — readiness + clean core check]
    MERGE[Merge to main]
    DEP[abapGit deploy to QAS / S/4HANA sandbox]
    TR[Transport Request — QAS → PRD]

    DEV -->|Develop object| AG
    AG -->|Push serialised files| GH
    GH -->|Open PR| PR
    PR -->|Trigger| CI
    CI --> AL
    CI --> ATC_CI
    CI --> SCAN
    AL -->|Pass / Fail| PR
    ATC_CI -->|Pass / Fail| PR
    SCAN -->|Readiness report| PR
    PR -->|Approved + checks pass| MERGE
    MERGE -->|Deploy hook| DEP
    DEP -->|Object import to QAS| TR

abaplint in CI

abaplint is an open-source static analyser for ABAP that runs entirely on the serialised files — no SAP system required. It checks syntax, style rules, naming conventions, and a configurable set of quality rules. Adding it to a GitHub Actions workflow is a few lines of configuration:

name: abaplint
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: abaplint/run-abaplint@v1
        with:
          abaplint_version: latest

abaplint’s rule set is configured in .abaplint.json at the repository root. For S/4HANA migration projects, the most valuable rules are those that flag deprecated syntax (SELECT *, MOVE-CORRESPONDING, ASSIGN COMPONENT, use of pool/cluster tables) before the code ever reaches the system.

ATC integration

For teams with access to an S/4HANA sandbox or cloud system, the ATC (ABAP Test Cockpit) can be triggered via the SAP Cloud Platform ABAP Environment’s REST API. This gives CI access to the full ATC rule set including the S/4HANA readiness variant — the authoritative check for deprecated API usage, missing clean core compliance, and Simplification Database violations. abaplint and ATC are complementary: abaplint is fast and system-free; ATC is slower but authoritative.

s4ready scanning in CI

s4ready’s A1 Readiness Agent can be triggered against a Git repository via the platform API. It reads the serialised ABAP files from the repository, runs the full 30+ rule readiness analysis, and posts a structured JSON report that can be consumed by CI tooling. For pull requests touching objects in a migration backlog, this means every PR gets a readiness delta: what changed, what new issues were introduced, whether the clean core score improved or regressed.

This is one of the core use cases abapGit enables: because the source is in Git, tooling can scan it without connecting to a SAP system. The scan is fast enough to run on every pull request, which turns the readiness backlog from a one-time assessment into a continuously measured metric.

Practical setup checklist

For teams new to abapGit:

1. Install abapGit in your development system — the standalone version (a single program ZABAPGIT_STANDALONE) or the full online version. Installation is itself done via abapGit or manual import.
2. Create a remote repository (GitHub, GitLab, Azure DevOps) with appropriate access controls. The SAP system needs network access to the Git host; configure this in SM59 if needed.
3. Choose packages carefully — abapGit works at the package level. Start with a single self-contained custom package to validate the workflow before broader adoption.
4. Set up .abapgit.xml at the repository root to fix the package and serialisation settings.
5. Add abaplint to CI immediately — before the first push — so the baseline is clean.
6. Define a branching convention your team will actually follow. Start simple: main for production-ready code, develop for integration, feature/<name> for in-progress work.
7. Document the transport workflow explicitly: when does a developer create a transport? At what point does abapGit pull feed into the transport?

How s4ready uses abapGit repositories

s4ready’s scanning agents are designed around abapGit repositories as the primary input. When a customer connects their abapGit repository, the A1 Readiness Agent has access to the full ABAP source without requiring a live RFC connection to the SAP system. This means:

• Scans can run in the cloud, without VPN or RFC connectivity to on-premise systems
• Historical analysis is possible — scan any commit in the repository’s history
• Scan results are reproducible and auditable — tied to a specific commit SHA
• CI/CD integration is straightforward — trigger a scan via API on push or PR

For organisations that have not yet adopted abapGit, we offer a guided setup as part of onboarding. The alternative — RFC-based extraction from a live system — works but loses the Git history and the CI integration that makes continuous readiness tracking possible.

Connect your abapGit repository →

---

abapGit is an open-source project not affiliated with SAP SE. SAP, ABAP, ATC, CTS, and related marks are trademarks of SAP SE.