abapGit: Git-Versionierung für ABAP-Code

kategorie

DevOps

Veröffentlicht

Feb 14, 2026

autor

abapGit ist das Open-Source-Tool der ABAP-Community, das Git-Versionierung für ABAP-Entwicklungsobjekte ermöglicht. Es serialisiert ABAP-Objekte in textbasierte Dateien, die in Git-Repositories gespeichert werden können. Damit bringst du moderne Versionskontrolle, Code Reviews und CI/CD-Pipelines in die ABAP-Welt.

Was ist abapGit?

abapGit ist ein in ABAP geschriebenes Git-Client-Tool, das:

Feature	Beschreibung
Serialisierung	ABAP-Objekte in XML/JSON-Dateien umwandeln
Git-Integration	Push, Pull, Branch, Merge direkt aus SAP
Offline-Support	Export/Import als ZIP-Dateien
Open Source	Community-getrieben auf GitHub

Vorteile von abapGit

Versionskontrolle: Vollständige Git-Historie für ABAP-Code
Code Reviews: Pull Requests und Reviews auf GitHub/GitLab
Backup: Externe Sicherung des gesamten ABAP-Codes
Sharing: Open-Source-ABAP-Projekte teilen
CI/CD: Integration in moderne DevOps-Pipelines

Installation von abapGit

abapGit kann auf verschiedene Arten installiert werden:

Standalone Version (empfohlen für den Start)

Lade die aktuelle Version von abapGit Releases herunter
Erstelle einen neuen Report ZABAPGIT_STANDALONE in SE38/ADT
Kopiere den kompletten Quellcode in den Report
Aktiviere und führe den Report aus

Developer Version (für regelmäßige Updates)

" 1. Erstelle ein Package für abapGit
" 2. Klone das abapGit-Repository selbst mit der Standalone-Version
" 3. Repository-URL: https://github.com/abapGit/abapGit.git

abapGit in ADT (Eclipse)

Für ADT gibt es das abapGit Eclipse Plugin:

Help → Install New Software
URL: https://eclipse.abapgit.org/updatesite/
abapGit for ABAP Development Tools auswählen
Installation abschließen und Eclipse neu starten

Repository erstellen und verbinden

Neues Repository anlegen

CLASS zcl_abapgit_example DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

ENDCLASS.

CLASS zcl_abapgit_example IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    " Dieses Beispiel zeigt die Schritte konzeptuell
    " Die eigentliche Arbeit erfolgt über die abapGit UI

    out->write( '=== abapGit Repository Setup ===' ).
    out->write( '1. Transaktion ZABAPGIT oder Report starten' ).
    out->write( '2. "+ Online" für neues Git-Repository' ).
    out->write( '3. Repository-URL eingeben' ).
    out->write( '4. Package auswählen oder erstellen' ).
    out->write( '5. Branch auswählen (meist "main")' ).
  ENDMETHOD.

ENDCLASS.

Lokales Package mit Git verbinden

So verbindest du ein bestehendes Package mit einem Git-Repository:

abapGit starten: Transaktion ZABAPGIT oder Report ausführen
Repository hinzufügen: Klick auf ”+ Online”
URL eingeben: z.B. https://github.com/username/my-abap-project.git
Package auswählen: Bestehendes Package wie ZRAP_DEMO
Authentifizierung: GitHub-Token für private Repos

Repository klonen

Um ein bestehendes Repository zu klonen:

1. abapGit öffnen
2. "+ Online" klicken
3. Repository-URL: https://github.com/SAP-samples/abap-platform-rap-opensap.git
4. Neues Package erstellen: ZRAP_OPENSAP
5. Branch: main
6. "Clone" ausführen

Stage, Commit, Push Workflow

Der typische Git-Workflow in abapGit:

Änderungen anzeigen (Status)

Nach Änderungen an deinem ABAP-Code:

Öffne das Repository in abapGit
Klicke auf “Stage”
Du siehst alle geänderten Objekte

Staging und Commit

Workflow in der abapGit UI:

1. Repository öffnen → "Stage" klicken
2. Änderungen reviewen:
   - Grün (+): Neue Objekte
   - Gelb (~): Geänderte Objekte
   - Rot (-): Gelöschte Objekte
3. Objekte für Commit auswählen (Stage)
4. Commit-Message eingeben
5. "Commit" klicken

Push zum Remote Repository

Nach dem Commit:

1. "Push" Button in der Repository-Ansicht
2. Bei GitHub: Personal Access Token eingeben
3. Push wird ausgeführt
4. Änderungen sind im Remote-Repository sichtbar

Praktisches Beispiel: Vollständiger Workflow

CLASS zcl_abapgit_workflow DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

    METHODS process_order
      IMPORTING
        iv_order_id TYPE i
      RETURNING
        VALUE(rv_success) TYPE abap_bool.

ENDCLASS.

CLASS zcl_abapgit_workflow IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    " Beispiel: Diese Klasse wird mit abapGit versioniert
    DATA(lv_result) = process_order( 12345 ).

    IF lv_result = abap_true.
      out->write( 'Order processed successfully.' ).
    ELSE.
      out->write( 'Order processing failed.' ).
    ENDIF.
  ENDMETHOD.

  METHOD process_order.
    " Geschäftslogik hier
    " Nach Änderungen: Stage → Commit → Push
    rv_success = abap_true.
  ENDMETHOD.

ENDCLASS.

Git-Workflow für diese Änderung:

Klasse in ADT bearbeiten und aktivieren
abapGit öffnen → Repository auswählen
“Stage” → ZCL_ABAPGIT_WORKFLOW.clas.abap auswählen
Commit-Message: feat: Add order processing method
Commit → Push

Branches und Merging

Branch erstellen

In abapGit:

1. Repository öffnen
2. "Branch" Dropdown → "Create Branch"
3. Branch-Name eingeben: feature/new-validation
4. Basis-Branch: main
5. Branch erstellen

Der neue Branch ist jetzt aktiv.

Zwischen Branches wechseln

1. Repository in abapGit öffnen
2. "Branch" Dropdown klicken
3. Gewünschten Branch auswählen
4. "Switch" bestätigen

WICHTIG: Ungespeicherte Änderungen werden überschrieben!

Pull Request Workflow

Der empfohlene Workflow für Team-Entwicklung:

1. Neuen Feature-Branch erstellen
   → feature/customer-validation

2. Änderungen entwickeln und testen
   → Neue Validierungslogik implementieren

3. Stage, Commit, Push
   → Commit: "feat: Add customer credit validation"

4. Pull Request auf GitHub/GitLab erstellen
   → feature/customer-validation → main

5. Code Review durch Team-Kollegen
   → Reviewer prüfen die Änderungen

6. Merge nach Approval
   → PR wird in main gemerged

7. Main-Branch in SAP ziehen
   → Pull in abapGit ausführen

Merge-Konflikte behandeln

Bei Konflikten zwischen Branches:

1. Pull schlägt fehl mit Konfliktmeldung
2. Konflikt extern lösen:
   - Repository lokal klonen (git clone)
   - Merge durchführen (git merge)
   - Konflikte in Editor lösen
   - Commit und Push
3. In abapGit: Pull erneut ausführen

.abapgit.xml Konfiguration

Die .abapgit.xml Datei im Repository-Root steuert das Verhalten von abapGit.

Grundstruktur

<?xml version="1.0" encoding="utf-8"?>
<asx:abap xmlns:asx="http://www.sap.com/abapxml" version="1.0">
 <asx:values>
  <DATA>
   <MASTER_LANGUAGE>D</MASTER_LANGUAGE>
   <STARTING_FOLDER>/src/</STARTING_FOLDER>
   <FOLDER_LOGIC>FULL</FOLDER_LOGIC>
   <IGNORE>
    <item>/.gitignore</item>
    <item>/LICENSE</item>
    <item>/README.md</item>
    <item>/.github/</item>
   </IGNORE>
   <REQUIREMENTS>
    <item>
     <component>SAP_BASIS</component>
     <min_release>756</min_release>
    </item>
   </REQUIREMENTS>
  </DATA>
 </asx:values>
</asx:abap>

Wichtige Einstellungen

Einstellung	Beschreibung	Werte
`MASTER_LANGUAGE`	Originalsprache	`D` (Deutsch), `E` (Englisch)
`STARTING_FOLDER`	Wurzelverzeichnis	`/src/`, `/`
`FOLDER_LOGIC`	Ordnerstruktur	`PREFIX`, `FULL`, `MIXED`
`IGNORE`	Ignorierte Dateien	Pfadliste

Folder Logic erklärt

PREFIX (Standard für flache Strukturen):
  /src/zcl_myclass.clas.abap
  /src/zif_myinterface.intf.abap

FULL (Empfohlen für große Projekte):
  /src/zpackage/
    /src/zpackage/zcl_myclass.clas.abap
    /src/zpackage/subpackage/
      /src/zpackage/subpackage/zcl_helper.clas.abap

MIXED (Kombination):
  /src/zpackage/
    zcl_myclass.clas.abap
    subpackage/
      zcl_helper.clas.abap

Beispiel: Projekt-Setup

<?xml version="1.0" encoding="utf-8"?>
<asx:abap xmlns:asx="http://www.sap.com/abapxml" version="1.0">
 <asx:values>
  <DATA>
   <MASTER_LANGUAGE>D</MASTER_LANGUAGE>
   <STARTING_FOLDER>/src/</STARTING_FOLDER>
   <FOLDER_LOGIC>FULL</FOLDER_LOGIC>
   <IGNORE>
    <item>/.gitignore</item>
    <item>/LICENSE</item>
    <item>/README.md</item>
    <item>/.github/</item>
    <item>/docs/</item>
   </IGNORE>
   <REQUIREMENTS>
    <item>
     <component>SAP_BASIS</component>
     <min_release>756</min_release>
    </item>
   </REQUIREMENTS>
   <ORIGINAL_SYSTEM>NPL</ORIGINAL_SYSTEM>
  </DATA>
 </asx:values>
</asx:abap>

abapGit vs. gCTS: Vergleich

SAP bietet mit gCTS (Git-enabled Change and Transport System) eine eigene Git-Integration. Hier der Vergleich:

Aspekt	abapGit	gCTS
Lizenz	Open Source	SAP-Lizenz erforderlich
Installation	Einfach (Report)	Systemkonfiguration
Flexibilität	Hoch	SAP-vorgegeben
Cloud-Support	Ja (BTP)	Ja (S/4HANA)
Transport-Integration	Optional	Vollständig
CI/CD	Extern (GitHub Actions)	SAP CI/CD Service
Lernkurve	Niedrig	Mittel
Enterprise-Support	Community	SAP-Support

Wann abapGit verwenden?

Open-Source-Projekte teilen
Externe Entwicklerteams einbinden
Flexible CI/CD-Pipelines (GitHub Actions, GitLab CI)
Backup und Dokumentation
Legacy-Systeme ohne gCTS

Wann gCTS verwenden?

Enge Integration mit SAP-Transportwesen
Enterprise-Support erforderlich
SAP CI/CD Service Nutzung geplant
Standardisierte SAP-Landschaft

Praktische Beispiele

Beispiel 1: ABAP-Projekt für Open Source vorbereiten

CLASS zcl_string_utils DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    "! Entfernt alle Leerzeichen aus einem String
    METHODS remove_spaces
      IMPORTING
        iv_input TYPE string
      RETURNING
        VALUE(rv_output) TYPE string.

    "! Kehrt einen String um
    METHODS reverse_string
      IMPORTING
        iv_input TYPE string
      RETURNING
        VALUE(rv_output) TYPE string.

    "! Prüft ob String ein Palindrom ist
    METHODS is_palindrome
      IMPORTING
        iv_input TYPE string
      RETURNING
        VALUE(rv_result) TYPE abap_bool.

ENDCLASS.

CLASS zcl_string_utils IMPLEMENTATION.

  METHOD remove_spaces.
    rv_output = iv_input.
    REPLACE ALL OCCURRENCES OF ` ` IN rv_output WITH ``.
  ENDMETHOD.

  METHOD reverse_string.
    rv_output = reverse( iv_input ).
  ENDMETHOD.

  METHOD is_palindrome.
    DATA(lv_cleaned) = to_lower( remove_spaces( iv_input ) ).
    DATA(lv_reversed) = reverse_string( lv_cleaned ).
    rv_result = xsdbool( lv_cleaned = lv_reversed ).
  ENDMETHOD.

ENDCLASS.

Repository-Struktur auf GitHub:

my-abap-utils/
├── .abapgit.xml
├── README.md
├── LICENSE
└── src/
    └── zcl_string_utils.clas.abap
    └── zcl_string_utils.clas.xml

Beispiel 2: CI/CD mit GitHub Actions

name: ABAP Lint

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install abaplint
        run: npm install -g @abaplint/cli

      - name: Run abaplint
        run: abaplint

abaplint.json Konfiguration:

{
  "global": {
    "files": "/src/**/*.*"
  },
  "syntax": {
    "version": "v756",
    "errorNamespace": "^(Z|Y)"
  },
  "rules": {
    "avoid_use": {
      "statics": true,
      "default": true
    },
    "line_length": {
      "length": 120
    },
    "method_length": {
      "statements": 50
    }
  }
}

Beispiel 3: Team-Entwicklung mit Feature Branches

CLASS zcl_customer_validator DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_validation_result,
        valid   TYPE abap_bool,
        message TYPE string,
      END OF ty_validation_result.

    METHODS validate_customer
      IMPORTING
        iv_customer_id TYPE i
      RETURNING
        VALUE(rs_result) TYPE ty_validation_result.

    METHODS validate_credit_limit
      IMPORTING
        iv_customer_id TYPE i
        iv_order_value TYPE p
      RETURNING
        VALUE(rs_result) TYPE ty_validation_result.

ENDCLASS.

CLASS zcl_customer_validator IMPLEMENTATION.

  METHOD validate_customer.
    " Feature entwickelt auf Branch: feature/customer-validation
    " Commit: "feat: Add basic customer validation"

    IF iv_customer_id <= 0.
      rs_result = VALUE #(
        valid   = abap_false
        message = 'Invalid customer ID'
      ).
      RETURN.
    ENDIF.

    " Kunde in Datenbank prüfen
    SELECT SINGLE @abap_true
      FROM scustom
      WHERE id = @iv_customer_id
      INTO @DATA(lv_exists).

    IF lv_exists = abap_true.
      rs_result = VALUE #(
        valid   = abap_true
        message = 'Customer valid'
      ).
    ELSE.
      rs_result = VALUE #(
        valid   = abap_false
        message = 'Customer not found'
      ).
    ENDIF.
  ENDMETHOD.

  METHOD validate_credit_limit.
    " Feature entwickelt auf Branch: feature/credit-validation
    " Commit: "feat: Add credit limit validation"

    " Erst Kunde validieren
    DATA(ls_customer_valid) = validate_customer( iv_customer_id ).
    IF ls_customer_valid-valid = abap_false.
      rs_result = ls_customer_valid.
      RETURN.
    ENDIF.

    " Kreditlimit prüfen
    SELECT SINGLE discount
      FROM scustom
      WHERE id = @iv_customer_id
      INTO @DATA(lv_limit).

    DATA(lv_credit_limit) = CONV p( lv_limit * 10000 ).

    IF iv_order_value <= lv_credit_limit.
      rs_result = VALUE #(
        valid   = abap_true
        message = |Order within credit limit ({ lv_credit_limit })|
      ).
    ELSE.
      rs_result = VALUE #(
        valid   = abap_false
        message = |Order exceeds credit limit ({ lv_credit_limit })|
      ).
    ENDIF.
  ENDMETHOD.

ENDCLASS.

Git-Historie für dieses Feature:

* 7a3f2b1 (HEAD -> main) Merge pull request #42: Credit validation
|\
| * 5c2d1e3 (feature/credit-validation) feat: Add credit limit validation
| * 2b1a0c4 feat: Add customer validation helper
|/
* 9f8e7d6 Initial commit

Best Practices

1. Commit-Messages

Verwende konventionelle Commit-Messages:

feat: Add customer validation endpoint
fix: Correct date calculation in report
docs: Update README with setup instructions
refactor: Extract common validation logic
test: Add unit tests for order processing

2. Branch-Naming

feature/customer-validation    # Neue Features
bugfix/date-calculation       # Fehlerbehebungen
hotfix/critical-security      # Dringende Fixes
refactor/extract-utils        # Code-Verbesserungen

3. Repository-Struktur

my-abap-project/
├── .abapgit.xml              # abapGit Konfiguration
├── .gitignore                # Ignorierte Dateien
├── README.md                 # Projektdokumentation
├── LICENSE                   # Lizenz
├── abaplint.json            # Linter-Konfiguration
├── .github/
│   └── workflows/
│       └── ci.yml           # CI/CD Pipeline
└── src/
    └── zpackage/            # ABAP-Objekte
        ├── zcl_class.clas.abap
        └── zif_interface.intf.abap

4. Sicherheit

NIEMALS in Git committen:
- Passwörter oder API-Keys
- System-spezifische Einstellungen
- Produktivdaten
- Personalisierten Code (Hardcoded User)

In .gitignore aufnehmen:
*.log
*.tmp
local_config.*

Troubleshooting

Häufige Probleme

SSL-Zertifikatsfehler:

Lösung: SSL-Zertifikate im SAP-System importieren
→ Transaktion STRUST
→ SSL Client (Standard) öffnen
→ Zertifikat von github.com importieren

Authentifizierungsfehler bei GitHub:

Lösung: Personal Access Token verwenden
1. GitHub → Settings → Developer Settings → Personal Access Tokens
2. Token mit 'repo' Scope erstellen
3. Token als Passwort in abapGit eingeben

Deserialisierungsfehler:

Lösung: Abhängigkeiten prüfen
- Werden alle referenzierten Objekte mit geklont?
- Stimmt die SAP-Basisversion?
- Sind erforderliche Packages vorhanden?

Fazit

abapGit bringt moderne Entwicklungspraktiken in die ABAP-Welt:

Versionskontrolle: Vollständige Historie aller Änderungen
Collaboration: Code Reviews und Team-Arbeit
Open Source: Projekte teilen und nutzen
CI/CD: Automatisierte Qualitätsprüfungen

Für Open-Source-Projekte und flexible Entwicklungsworkflows ist abapGit die erste Wahl. Für streng regulierte Enterprise-Umgebungen mit voller SAP-Unterstützung bietet gCTS eine Alternative.