Was ist Git? Versionskontrolle einfach erklärt
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: Git ist ein verteiltes Versionskontrollsystem, also ein Werkzeug, das den Verlauf von Änderungen an Dateien speichert. Damit kannst du Versionen vergleichen, frühere Inhalte wiederherstellen und die Arbeit mehrerer Personen zusammenführen. Git läuft lokal auf deinem Computer; für die grundlegende Arbeit brauchst du weder GitHub noch eine Internetverbindung.
Wofür wird Git verwendet?
Ohne Versionskontrolle entstehen schnell Dateien mit Namen wie projekt-final, projekt-final2 und projekt-korrigiert. Git ersetzt solche manuellen Kopien durch eine geordnete Historie. Jeden bewusst gespeicherten Arbeitsstand kannst du beschreiben, überprüfen und mit einem anderen vergleichen.
Git eignet sich besonders für Quellcode, Konfigurationen, Dokumentation und Artikel, die als einfacher Text gespeichert sind, etwa in Markdown. Es kann auch Fotos oder Office-Dokumente speichern, deren Änderungen aber meist nicht so übersichtlich darstellen wie Unterschiede zwischen Textzeilen. Bei großen Binärdateien, die häufig geändert werden, muss die Speicherung zusätzlich geplant werden.
Ein Beispiel: Du änderst ein Kontaktformular, und danach funktionieren die Benachrichtigungen nicht mehr. Wenn du frühere Arbeitsstände in Git gespeichert hast, kannst du genau prüfen, was sich geändert hat, und die fehlerhafte Änderung rückgängig machen. Du musst die vorherige Version nicht aus dem Gedächtnis rekonstruieren.
Repository, Commit und Branch – die Grundbegriffe
Ein Repository enthält die Historie eines Projekts sowie die Informationen, die Git zur Versionsverwaltung benötigt. In einem typischen lokalen Projekt liegen diese Daten im versteckten Verzeichnis .git neben den Arbeitsdateien, die du bearbeitest.
Ein Commit ist ein gespeicherter Stand der von Git verfolgten Dateien, der mit der bisherigen Historie verknüpft ist. Er enthält eine Kennung, Angaben zum Autor und eine Beschreibung. Eine gute Beschreibung wie „Validierung der E-Mail-Adresse korrigieren“ erklärt den Zweck einer Änderung besser als „Korrekturen“. Git erstellt nicht automatisch bei jedem Speichern einer Datei im Editor einen Commit.
Der Bereitstellungsbereich, auch Index oder Staging Area genannt, ermöglicht es dir, Änderungen für den nächsten Commit auszuwählen. So kannst du mehrere Dateien bearbeiten, eine Fehlerkorrektur und eine Aktualisierung der Dokumentation aber getrennt speichern. Dadurch lässt sich die Historie später leichter nachvollziehen.
Ein Branch, auch Zweig genannt, ist eine eigene Entwicklungslinie im Repository. Darin kannst du eine neue Funktion entwickeln, ohne sofort die Hauptversion des Projekts zu verändern. Beim Zusammenführen, auch Merge genannt, werden Änderungen aus verschiedenen Branches kombiniert.
Verteilt bedeutet, dass du beim üblichen Klonen eines Repositorys eine lokale Kopie seiner Historie erhältst und nicht nur Zugriff auf Dateien auf einem Server. Es gibt auch Klone mit eingeschränkter Historie. Im normalen Arbeitsablauf brauchst du keine Verbindung zu einem zentralen Server, um gespeicherte Änderungen anzusehen oder Commits zu erstellen.
Git und GitHub – was ist der Unterschied?
Git ist ein Werkzeug zur Versionskontrolle. GitHub ist ein Dienst, der unter anderem Git-Repositorys speichert und Funktionen für die Zusammenarbeit anbietet, etwa zur Prüfung von Änderungen oder zum Melden von Fehlern. Eine ähnliche Rolle übernehmen GitLab und Bitbucket; du kannst ein Repository auch auf einem eigenen Server betreiben.
Ein Remote-Repository ist eine zweite Kopie des Repositorys, die unter einer bestimmten Adresse erreichbar ist. Der Befehl push überträgt lokale Commits dorthin. fetch lädt Informationen und die Historie aus der entfernten Kopie herunter, ohne sie in den aktuellen Branch zu integrieren. Der Befehl pull lädt Änderungen herunter und integriert sie anschließend. Wie diese Integration erfolgt, hängt von den Einstellungen und den verwendeten Optionen ab.
Ein Commit allein veröffentlicht deine Arbeit also nicht im Internet. Auch das Übertragen von Änderungen an einen Hostingdienst bedeutet nicht unbedingt, dass sie öffentlich zugänglich werden: Die Sichtbarkeit wird durch die Zugriffsrechte des Repositorys bestimmt.
Erste Schritte: Änderungen zum ersten Mal speichern
Installiere Git anhand der Anleitung für dein Betriebssystem in der offiziellen Projektdokumentation. Im Terminal kannst du die Installation mit git --version überprüfen. Du kannst auch eine grafische Oberfläche oder die Git-Unterstützung deines Editors nutzen; der grundlegende Ablauf bleibt derselbe.
Führe in einem neuen Testverzeichnis folgende Befehle aus:
git init
git config user.name "Max Müller"
git config user.email "max (at) example.com"
Diese Autorenangaben gelten für das aktuelle Repository und dienen nicht zur Anmeldung. Wähle die Adresse bewusst: Die Angaben zum Autor sind Bestandteil der Commits und können für andere sichtbar werden, wenn du die Historie teilst.
Erstelle im Editor die Datei README.md, schreibe eine kurze Projektbeschreibung hinein und speichere sie. Führe anschließend folgende Befehle aus:
git status
git add README.md
git diff --staged
git commit -m "Projektbeschreibung hinzufügen"
git log --oneline
git status zeigt den Status der Dateien an. git add stellt die ausgewählten Inhalte für den Commit bereit, und mit git diff --staged kannst du sie vor dem Commit überprüfen. Die letzten beiden Befehle speichern den Arbeitsstand und zeigen die Historie in Kurzform an.
Zusammenarbeit und Grenzen von Git
Bei der Zusammenarbeit kann Git viele voneinander unabhängige Änderungen automatisch zusammenführen. Wenn jedoch zwei Personen denselben Abschnitt auf unvereinbare Weise ändern, kann ein Merge-Konflikt entstehen. Dann musst du den richtigen Inhalt manuell festlegen, die Dateien mit gelösten Konflikten durch git add kennzeichnen und den Vorgang abschließen. Git beurteilt nicht, welche Version inhaltlich richtig ist.
Passwörter, Zugangsschlüssel und andere Geheimnisse gehören nicht ins Repository. Die Datei .gitignore legt fest, welche noch nicht von Git verfolgten Dateien ignoriert werden sollen. Sie entfernt aber keine Daten, die bereits in der Historie gespeichert sind. Einen offengelegten Schlüssel musst du widerrufen oder ersetzen; ihn nur aus der neuesten Version zu entfernen, reicht nicht aus.
Git ersetzt auch keine vollständige Datensicherung: Es schützt weder ungespeicherte Änderungen noch Dateien außerhalb des Repositorys automatisch. Erstelle zum Einstieg zwei Commits in einem Testverzeichnis und vergleiche sie mit git diff HEAD~1 HEAD. So siehst du genau, wie Git Unterschiede zwischen gespeicherten Arbeitsständen darstellt.
Siehe auch: Was ist AGI?
Lesen Sie auch
