Git, KI-Teams & CI/CD

1. Das gemeinsame Gedächtnis

Git speichert versionierte Schnappschüsse (Snapshots) lokal. Ein Commit verbindet einen solchen Stand mit seiner Vorgeschichte und einer Beschreibung der Änderung. GitHub und GitLab ergänzen die Zusammenarbeit: Aufgaben (Issues), Änderungsprüfungen (Reviews) und Automatisierung. Git ist das Versionskontrollsystem; GitHub und GitLab sind Plattformen darum herum.

Ein Repository enthält den freigegebenen Projektkontext und nachvollziehbaren Quellcode. Passwörter, Zugriffsschlüssel (Secrets) und Produktionsdaten bleiben ausserhalb. Auch ein privates Repository ist kein geeigneter Passwortspeicher.

2. Eine Änderung, ein nachvollziehbarer Schritt

Vor dem Start mit git status den lokalen Zustand prüfen und mit git fetch die Informationen vom entfernten Repository aktualisieren. Fetch integriert die Änderungen noch nicht in den eigenen Arbeitsbranch. Für die Aufgabe einen kurzlebigen Entwicklungszweig (Branch) von der vereinbarten Ausgangsversion erstellen.

Kleine, verständliche Commits halten Absicht und Änderung zusammen. Vor jedem Commit den Unterschied (Diff) prüfen. Mit git add gezielt Dateien auswählen und mit git diff --staged die tatsächlich vorgemerkten Änderungen kontrollieren. Eine aussagekräftige Commit-Nachricht erklärt den Zweck. Fachlich zusammengehörende Änderungen und die passenden Tests bilden einen nachvollziehbaren Schritt.

3. Menschen und KI-Agenten parallel

Jede Aufgabe braucht eine klare Zuständigkeit und ein überprüfbares Ergebnis. Mit git worktree add lassen sich zusätzliche Arbeitsverzeichnisse (Worktrees) anlegen, üblicherweise auf unterschiedlichen Branches. Jedes besitzt seinen eigenen ausgecheckten Arbeitsstand; die Worktrees teilen sich wesentliche Repository-Daten und Referenzen. Worktrees sind keine vollständig unabhängigen Klone.

Getrennte Verzeichnisse verhindern keine fachlichen Konflikte. Schnittstellen und Zuständigkeiten für Dateien weiterhin abstimmen; Änderungen anderer Personen oder Agenten nicht ungeprüft zurücksetzen. KI-Agenten erhalten nur die benötigten Zugänge. Secrets bleiben ausserhalb des Repositorys und gehören weder in Prompts noch in Testausgaben oder Protokolle.

4. Review vor Integration

Den Branch übertragen (Push) und einen Pull Request auf GitHub oder einen Merge Request auf GitLab öffnen. Beide Begriffe bezeichnen hier den Vorschlag, eine Änderung prüfen und in den Zielbranch integrieren zu lassen. Problem, resultierendes Verhalten und ausgeführte Prüfungen beschreiben, damit eine andere Person die Änderung beurteilen kann.

Den Hauptbranch passend zur Plattform und deren Funktionsumfang schützen: direkte Änderungen einschränken und erforderliche Reviews sowie erfolgreiche Prüfungen festlegen. Eine grüne Pipeline ersetzt kein fachliches Review. Nach weiteren Commits erneut prüfen, ob Freigaben und Prüfergebnisse noch zum aktuellen Stand gehören.

5. CI ist ein prüfbarer Ablauf

Kontinuierliche Integration (Continuous Integration, CI) prüft Änderungen automatisiert. GitHub Actions verwendet Workflow-Dateien unter .github/workflows, GitLab CI/CD in der Regel eine .gitlab-ci.yml. Eine Pipeline umfasst einzelne Aufgaben (Jobs), die beispielsweise Syntax, Verhalten und Sicherheitsgrenzen prüfen oder ein auslieferbares Ergebnis bauen.

Festgelegte Abhängigkeitsversionen und nachvollziehbare Build-Ergebnisse (Artifacts) machen Abläufe reproduzierbarer. Protokolle und Testberichte müssen zum geprüften Commit passen. Ein erfolgreicher Build und eine erfolgreiche Bereitstellung (Deployment) sind unterschiedliche Nachweise. CD kann Continuous Delivery bedeuten, bei der die Freigabe zur Produktion noch ein eigener Schritt ist, oder Continuous Deployment mit automatischer Produktionsbereitstellung.

6. Container und Auslieferung

Container-Images in der CI bauen und in eine private Image-Ablage (Container Registry) übertragen. Für eine konkrete Auslieferung das geprüfte Image über seinen kryptografischen Inhaltsbezeichner (Digest) beziehen. Ein veränderbarer Tag allein identifiziert keine unveränderliche Image-Version.

Laufende Daten und Secrets gehören in geschützte persistente Verzeichnisse oder dafür geeignete Secret-Verwaltung. Den Zugriff auf Registry und Zielsystem getrennt und mit den jeweils nötigen Rechten vergeben. Nach dem Start Anwendung, Proxy, TLS, Anmeldung und Persistenz tatsächlich prüfen. Für einen Rückweg (Rollback) die vorherige Image-Version und eine geprüfte Sicherung bereithalten. Ein älteres Image allein macht inkompatible Datenbankänderungen nicht rückgängig.

7. Konflikt und Rückweg

Vor einer Konfliktlösung git status und den betroffenen Diff lesen. Die beabsichtigte Wirkung beider Änderungen verstehen, Konfliktmarkierungen bewusst auflösen und das zusammengeführte Verhalten prüfen. Ein syntaktisch erfolgreicher Merge beweist noch keine fachliche Korrektheit.

Im gemeinsamen Verlauf lässt sich eine Änderung mit git revert durch einen neuen Commit nachvollziehbar rückgängig machen. Bei Merge-Commits muss zusätzlich der passende Haupteltern-Commit (Mainline Parent) gewählt werden. git reflog hilft, frühere lokale Referenzstände wiederzufinden; es ist kein Ersatz für ein Backup. git reset --hard und ein erzwungenes Übertragen (Force Push) können Arbeit entfernen oder gemeinsamen Verlauf umschreiben: zuerst den Zustand sichern, Zuständigkeiten klären und die Auswirkungen verstehen.

Praxisübung

Ein getrenntes Übungsrepository mit einem Remote auf GitHub oder GitLab und einen Aufgabenbranch erstellen. Keine Produktionsdaten oder Zugangsschlüssel in den Übungsdateien ablegen.
Eine kleine Änderung und einen aussagekräftigen Test erstellen. Diff und vorgemerkte Änderungen prüfen, Tests ausführen und committen.
In einem zweiten Worktree auf einem anderen Branch eine unabhängige Änderung durchführen. Die Zuständigkeiten vorher festlegen.
Einen Pull Request oder Merge Request öffnen und nach erfolgreicher CI und Review integrieren. Prüfen, dass die Ergebnisse zum integrierten Stand gehören.
Die integrierte Änderung mit git revert zurücknehmen und das Ergebnis erneut prüfen. Falls ein Merge-Commit zurückgenommen werden soll, zuerst die Bedeutung des Mainline Parents nachlesen.

In diesem Lernpfad bündeln wir unsere Unterlagen zur Zusammenarbeit mit Git, GitHub und GitLab in einer redaktionell überarbeiteten Webfassung. Befehle nur im Übungsrepository ausprobieren.

Begriffe: Englisch und Deutsch

Repository: versionierter Projektbestand mit Verlauf; ein lokales Repository kann auch ohne Plattform verwendet werden.
Commit / Snapshot: gespeicherter Versionsstand mit Vorgeschichte / Schnappschuss der versionierten Dateien.
Branch: Entwicklungszweig; technisch eine bewegliche Referenz auf einen Commit.
Staging Area / Index: Vormerkbereich für den nächsten Commit.
Diff: angezeigter Unterschied zwischen zwei Ständen.
Fetch / Push: Informationen und Objekte vom Remote holen / lokale Referenzstände an ein Remote übertragen.
Pull Request / Merge Request: prüfbarer Integrationsvorschlag auf GitHub / GitLab.
Worktree: zusätzliches Arbeitsverzeichnis desselben Repositorys mit eigenem ausgechecktem Stand.
Pipeline / Job: automatisierter Ablauf / einzelne Aufgabe darin.
Artifact: aufbewahrtes Ergebnis eines Jobs, etwa ein Testbericht oder ein Build-Paket.
Container Registry / Digest: Ablage für Container-Images / kryptografischer Inhaltsbezeichner eines Images oder Manifests.
Deployment / Rollback: Bereitstellung einer Version / Rückkehr zu einem früheren betriebsfähigen Stand.
Revert / Reflog: Änderungen durch einen neuen Commit rückgängig machen / lokales Protokoll früherer Referenzstände.

Quellen

Die englischen Originalbegriffe und die genaue Syntax stehen in den offiziellen Dokumentationen. Dieser Lernpfad fasst die für die Zusammenarbeit wichtigen Zusammenhänge zusammen.