Git ist ein verteiltes Versionskontrollsystem. Es hält Änderungen an Dateien als nachvollziehbare Versionen fest und ermöglicht, Entwicklungen zu vergleichen, zusammenzuführen oder auf einen früheren Stand zurückzuführen. Die offizielle Git-Dokumentation beschreibt Versionsverwaltung als Aufzeichnung von Änderungen über die Zeit.
Git wird vor allem für Quellcode verwendet, eignet sich aber ebenso für Markdown, Konfigurationen, technische Dokumentation und andere textbasierte Inhalte.
Ein Repository bewahrt Geschichte
Ein Repository enthält die Dateien eines Projekts und ihre Versionsgeschichte. Eine Änderung wird nicht automatisch dauerhaft. Zuerst wird sie ausgewählt und anschliessend als Commit gespeichert. Ein guter Commit hält einen zusammengehörenden Schritt fest und erklärt knapp, weshalb er vorgenommen wurde.
Git denkt dabei in Snapshots. Jeder Commit verweist auf einen vollständigen Projektzustand, ohne unveränderte Dateien unnötig zu duplizieren. Dadurch lassen sich zwei Stände vergleichen und einzelne Entscheidungen später rekonstruieren.
Branches trennen Arbeitsstände
Ein Branch ist eine bewegliche Referenz auf eine Reihe von Commits. Er erlaubt, eine Funktion oder Korrektur abseits des gemeinsamen Hauptstands zu entwickeln. Erst nach Prüfung wird dieser Arbeitsstand zusammengeführt.
Branches ersetzen keine Qualitätskontrolle. Sie schaffen lediglich einen abgegrenzten Raum, in dem eine Änderung vorbereitet werden kann. Tests, Review und ein verständlicher Diff bleiben notwendig.
Lokal und remote
Git funktioniert lokal. Ein Remote-Repository dient als gemeinsamer Austauschpunkt und zusätzliche Kopie der Projektgeschichte. GitHub und GitLab sind Plattformen, die Git um Zugriffssteuerung, Reviews, Issues, Automationen und weitere Funktionen ergänzen. Sie sind nicht Git selbst.
Wer ein Repository klont, erhält standardmässig nicht nur die aktuellen Dateien, sondern auch die Versionsgeschichte. Änderungen können lokal erstellt und später an ein Remote übertragen werden.
Was in Git gehört
Gut geeignet sind:
- Quellcode und Tests,
- Dokumentation und Architekturentscheidungen,
- deklarative Konfigurationen,
- kleine, nachvollziehbare Daten- oder Beispieldateien,
- Skripte für Build, Prüfung und Betrieb.
Nicht in ein Repository gehören Passwörter, Tokens, private Schlüssel oder unkontrollierte Laufzeitdaten. Auch grosse Binärdateien und generierte Build-Ausgaben benötigen eine bewusste Ablagestrategie. Eine Datei aus der aktuellen Version zu löschen entfernt sie zudem nicht automatisch aus der früheren Git-Geschichte.
Ein kontrollierter Grundablauf
Ein belastbarer Arbeitsablauf besteht aus wenigen wiederkehrenden Schritten:
1. Den aktuellen Stand und fremde Änderungen prüfen.
2. Einen abgegrenzten Arbeitsstand verwenden.
3. Änderungen in kleinen, fachlich zusammengehörenden Schritten umsetzen.
4. Diff, Tests und unbeabsichtigte Dateien kontrollieren.
5. Nur die zum Auftrag gehörenden Dateien committen.
6. Den geprüften Stand zusammenführen und erst danach veröffentlichen.
Bei produktiven Änderungen dokumentiert Git die Quelle. Es beweist noch nicht, dass derselbe Stand tatsächlich gebaut, ausgeliefert oder im Zielsystem wirksam wurde. Dafür braucht es zusätzlich Build-Evidenz, Freigabe und einen überprüften Readback.
Git als Wissensgrundlage
In einer Knowledge Base macht Git nicht nur Textänderungen sichtbar. Es zeigt, wann eine Regel angepasst wurde, welche Begründung dazugehörte und welche Fassung vorher galt. Zusammen mit offenen Textformaten entsteht Wissen, das durchsucht, geprüft und automatisiert verarbeitet werden kann, ohne an einen einzelnen Editor gebunden zu sein.
Merksatz
Git bewahrt nicht bloss Dateien, sondern Entscheidungen über Dateien. Verlässlich wird diese Geschichte erst, wenn Commits abgegrenzt, verständlich und überprüft sind.