Git entstand 2005 für die Entwicklung des Linux-Kernels und ist heute in der Softwareentwicklung weit verbreitet. Statt Versionsverwaltung ist auch von Versionskontrolle die Rede. Wer Software entwickelt, Server per Skript konfiguriert oder Infrastructure as Code einsetzt, arbeitet fast immer mit Git. Plattformen wie GitHub, GitLab, Azure Repos oder Bitbucket ergänzen Git um Zusammenarbeit im Browser, Berechtigungen, Reviews und Automatisierung.
Wie Git funktioniert
- Schnappschüsse: Laut dem offiziellen Git-Buch speichert Git Daten als Folge von Schnappschüssen eines kleinen Dateisystems, nicht als Liste einzelner Dateiänderungen.
- Verteilt und lokal: Jede Arbeitskopie enthält die vollständige Historie. Die meisten Vorgänge brauchen deshalb nur lokale Dateien und funktionieren auch ohne Netzwerk.
- Integrität: Alles wird vor dem Speichern mit einer Prüfsumme versehen und über diese referenziert. Unbemerkte Veränderungen an der Historie fallen dadurch auf.
- Drei Zustände: Eine Datei ist geändert, zum nächsten Stand vorgemerkt oder dauerhaft gespeichert, in Git-Begriffen modified, staged und committed.
Die wichtigsten Begriffe im Alltag:
- Commit: ein gespeicherter Stand mit Beschreibung, Autorin oder Autor und Zeitpunkt
- Branch: ein Entwicklungszweig, in dem eine Änderung unabhängig vom Hauptstand entsteht
- Merge: das Zusammenführen zweier Zweige
- Remote: ein entferntes Repository, mit dem Stände per Push und Pull abgeglichen werden
- Pull Request: auf Plattformen die Anfrage, einen Zweig nach Prüfung in den Hauptstand zu übernehmen
Typische Arbeitsweise im Team
- Für jede Aufgabe einen eigenen, kurzlebigen Branch anlegen.
- In kleinen, gut beschriebenen Commits arbeiten.
- Einen Pull Request eröffnen, der automatisch getestet wird, siehe CI/CD.
- Die Änderung im Code Review prüfen lassen.
- Nach Freigabe in den Hauptzweig übernehmen und den Branch löschen.
- Auslieferungsstände mit Tags kennzeichnen, damit jede Version eindeutig wiederherstellbar ist.
Eine Datei namens .gitignore legt fest, was nie ins Repository gehört, etwa Abhängigkeiten, die Composer neu installiert, oder lokale Konfigurationsdateien.
Git außerhalb der Softwareentwicklung
- PowerShell- und Automatisierungsskripte der IT nachvollziehbar pflegen
- Konfigurationen von Firewalls, Servern oder Cloud-Umgebungen als Dateien versionieren
- Technische IT-Dokumentation im Markdown-Format mit Änderungshistorie führen
- Website-Inhalte über geprüfte Pull Requests veröffentlichen
Sicherheit
- Keine Geheimnisse ins Repository: Git vergisst nichts. Ein einmal eingechecktes Passwort steckt in der Historie, auch wenn die Datei später gelöscht wird. GitHub beschreibt, wie sich solche Daten nachträglich entfernen lassen, und betont, dass betroffene Zugangsdaten trotzdem sofort ersetzt werden müssen.
- Zugriffe steuern: Rechte je Repository vergeben, Plattformkonten mit Multi-Faktor-Authentifizierung schützen und beim Offboarding Tokens und SSH-Schlüssel entziehen.
- Hauptzweig schützen: Geschützte Branches verlangen vor dem Übernehmen Reviews und erfolgreiche Prüfungen und verhindern das Überschreiben der Historie.
- Sichern: Ein gehostetes Repository ist kein Backup. Wichtige Repositories gehören in die Backup-Strategie.
Abgrenzung
Git ist die Software, GitHub oder GitLab sind Plattformen, die Git-Repositories bereitstellen und ergänzen. Die Versionierung in SharePoint oder OneDrive speichert ältere Fassungen einzelner Dokumente, bietet aber keine Zweige, kein Zusammenführen und keine Reviews. Ein Backup sichert Daten gegen Verlust. Git dokumentiert, wer was wann und warum geändert hat.
Häufige Fragen
Lohnt sich Git auch für kleine Projekte?
Ja. Schon für eine einzelne Person bringt Git eine lückenlose Historie, die Möglichkeit, frühere Stände wiederherzustellen, und Branches, in denen sich Ideen gefahrlos ausprobieren lassen. Der Aufwand ist gering, denn ein Repository entsteht mit einem einzigen Befehl.
Wie macht man eine Änderung rückgängig?
Auf gemeinsam genutzten Zweigen erzeugt git revert einen neuen Commit, der die Wirkung eines früheren Commits aufhebt. Die Historie bleibt dabei erhalten und für alle nachvollziehbar. Befehle, die die Historie umschreiben, sind nur für lokale, noch nicht geteilte Stände gedacht.
Ersetzt Git ein Backup?
Nein. Verteilte Kopien helfen zwar, wenn ein Rechner ausfällt, schützen aber nicht vor versehentlich gelöschten Repositories auf der Plattform, gesperrten Konten oder Ransomware. Dafür braucht es eine eigene Sicherung.