Auch genannt: Git wird üblicherweise ohne ausgeschriebene Langform verwendet. Der Begriff bezeichnet das Versionskontrollsystem, nicht einen bestimmten Hostingdienst.
Git ist ein verteiltes Versionskontrollsystem. Es hält fest, welche Dateien zu einem bestimmten Zeitpunkt zusammengehören, welche Änderungen zwischen zwei Ständen liegen und wie diese Stände miteinander verbunden sind. So lassen sich frühere Zustände nachvollziehen, vergleichen und bei Bedarf wiederherstellen. Die offizielle Git-Dokumentation beschreibt Git als skalierbares, verteiltes System zur Versionskontrolle; Versionskontrolle allgemein zeichnet Änderungen an Dateien über die Zeit auf. Git-Dokumentation und Git Book
Statt Ordner wie projekt-final, projekt-final-neu und projekt-final-wirklich zu kopieren, kann ein Projekt in Git als Folge bewusst gespeicherter Stände geführt werden. Ein solcher gespeicherter Stand heißt Commit. Zu einem Commit gehören die Inhalte, die aufgenommen wurden, sowie Verweise auf frühere Commits. Damit beantwortet Git Fragen wie: Was hat sich geändert? Wann wurde ein Fehler eingeführt? Welcher Stand war vor einer Umstellung gültig?
Das ist nicht nur für Quellcode nützlich. Auch Texte, Konfigurationsdateien, technische Dokumentation oder Datenmodelle können versioniert werden, sofern sie als Dateien vorliegen. Ein konkretes Beispiel aus dem redaktionellen Umfeld: Ein lokales Wissensarchiv aus Markdown-Dateien kann mit Git versionskontrolliert werden; der Artikel von Digital-Magazin beschreibt diese Rolle von Git in einem Obsidian-basierten Wissenssystem. Digital-Magazin: Zweites Gehirn mit KI
Git arbeitet verteilt. Wer ein Repository klont, erhält nicht bloß die aktuelle Arbeitskopie, sondern normalerweise auch die bisherige Historie. Deshalb ist ein zentraler Server für die lokale Arbeit nicht zwingend erforderlich. Das macht Git jedoch nicht automatisch zu einer vollständigen Datensicherungsstrategie: Ein Clone kann eine wertvolle Kopie sein, ersetzt aber keine geplante Sicherung wichtiger Daten und Zugänge.
Im Alltag lassen sich vier Begriffe auseinanderhalten. Das Arbeitsverzeichnis enthält die Dateien, die gerade bearbeitet werden. Mit dem Index, oft auch Staging Area genannt, wird ausgewählt, welche Änderungen in den nächsten Commit eingehen. Ein Commit speichert dann einen nachvollziehbaren Projektstand. Ein Repository umfasst die Historie und die dazugehörigen Git-Daten.
Git speichert diese Historie als Objektdatenbank. Die offizielle Dokumentation unterscheidet dabei unter anderem Blobs für Dateiinhalte, Trees für Verzeichnisstrukturen und Commits, die auf einen Tree und ihre Vorgänger verweisen. Branches sind benannte Entwicklungslinien: Sie zeigen jeweils auf einen aktuellen Commit und können sich unabhängig weiterentwickeln. Werden zwei Linien zusammengeführt, entsteht je nach Ergebnis ein Merge-Commit oder ein aufgelöster Konflikt. Git: technische Grundlagen
Eine typische Folge sieht so aus: Zunächst werden Dateien bearbeitet. Danach prüft man mit git status, welche Änderungen vorliegen. Mit git add werden die gewünschten Änderungen für den nächsten Commit vorgemerkt. git commit schreibt den ausgewählten Stand mit einer Nachricht in die lokale Historie. Erst git push überträgt lokale Commits an ein konfiguriertes entferntes Repository. Diese Trennung ist wichtig: Ein Commit ist kein automatischer Upload, und ein Push ist kein Ersatz für sorgfältige Prüfung.
Ein Team ergänzt eine Funktion in einer Anwendung. Eine Entwicklerin legt dafür einen Branch an, damit die Arbeit nicht sofort den gemeinsamen Hauptzweig verändert. Sie passt mehrere Dateien an, führt Tests aus und erstellt einen Commit mit einer verständlichen Nachricht. Ein Kollege arbeitet parallel an einer anderen Aufgabe. Sind beide Änderungen bereit, werden sie geprüft und zusammengeführt.
Wenn beide dieselbe Stelle unterschiedlich verändert haben, kann Git den Inhalt nicht immer sinnvoll selbst kombinieren. Dann meldet es einen Konflikt. Das ist kein Defekt des Werkzeugs, sondern ein Hinweis, dass eine fachliche Entscheidung nötig ist: Welche Fassung soll gelten, oder wie werden beide Änderungen kombiniert? Nach der Auflösung wird der resultierende Inhalt erneut getestet. Hier ergänzt Git den Softwaretest, ersetzt ihn aber nicht.
Auch bei einem kleinen Einzelprojekt lohnt sich dieselbe Denkweise. Eine Dokumentation kann vor einer Überarbeitung committed werden. Erweist sich die neue Gliederung als ungeeignet, lässt sich der frühere Stand gezielt ansehen oder wiederherstellen. Entscheidend ist, Änderungen in sinnvollen, überprüfbaren Einheiten zu speichern, statt nur selten große Sammelstände anzulegen.
Git ist vor allem ein Werkzeug für die Zusammenarbeit an Software. Teams nutzen es, um Änderungen zu prüfen, Releases zu markieren und parallele Aufgaben voneinander zu trennen. Plattformen wie GitHub, GitLab oder selbst betriebene Server können Git-Repositorys bereitstellen und zusätzliche Funktionen wie Zugriffsverwaltung, Tickets oder Code-Reviews anbieten. Diese Plattformen sind jedoch nicht Git selbst; Git kann auch ohne einen bestimmten Anbieter lokal oder mit einem anderen Server verwendet werden.
Darüber hinaus wird Git für Dokumentation, Website-Quelltexte, Infrastrukturkonfiguration und andere dateibasierte Arbeitsstände eingesetzt. Bei quelloffenen Projekten erleichtert es, Änderungen transparent vorzuschlagen und die Entwicklungshistorie nachzuvollziehen. Wie Offenheit von Code rechtlich und organisatorisch geregelt wird, erklärt der verwandte Begriff Open Source.
Git bewahrt Historie, aber es bewertet keine Qualität. Ein Commit kann fehlerhaften, unsicheren oder unvollständigen Inhalt enthalten. Deshalb bleiben Review, Tests und klare Regeln für Zugriffsrechte wichtig. Ebenso führt ein Versionsverlauf nicht von allein zu einer verständlichen Dokumentation: Commit-Nachrichten und die sinnvolle Aufteilung von Änderungen prägen, wie gut sich eine Historie später lesen lässt.
Ein verbreitetes Missverständnis lautet, ein Remote-Repository sei automatisch eine Sicherung aller Daten. Das hängt von Übertragung, Aufbewahrungsregeln, Berechtigungen und davon ab, welche Dateien überhaupt eingecheckt wurden. Zugangsdaten, private Schlüssel oder andere Geheimnisse gehören grundsätzlich nicht unbedacht in ein Repository. Die Git-Dokumentation weist außerdem darauf hin, dass Konfigurationen und Hooks aus einem nicht vertrauenswürdigen .git-Verzeichnis beim Ausführen von Git-Befehlen riskant sein können. Sicherheitshinweise in der Git-Dokumentation
Auch der Gedanke, Git speichere einfach nur Dateidifferenzen, greift zu kurz. Git arbeitet im Kern mit Zuständen und ihren Verweisen. Diffs sind eine sehr hilfreiche Ansicht für Menschen, beschreiben aber nicht vollständig, wie Git seine Historie intern modelliert.
GitHub, GitLab und ähnliche Dienste sind Plattformen, die Git-Repositorys hosten und zusätzliche Zusammenarbeit anbieten können. Git ist das Versionskontrollsystem darunter.
Backup ist eine geplante Datensicherung mit eigenen Regeln für Kopien, Aufbewahrung und Wiederherstellung. Git-Historie kann Teil einer Schutzstrategie sein, ist aber nicht automatisch ein vollständiges Backup.
Branch ist keine zweite Kopie eines ganzen Projekts im Alltagsverständnis, sondern eine benannte Entwicklungslinie, die auf Commits verweist.