So funktioniert Git — Momentaufnahmen, Branches und Historie

So funktioniert Git — Momentaufnahmen, Branches und Historie

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie die drei Spalten von links nach rechts: Bearbeiten, Commit, Teilen.
• Die vier Bahnengruppen sind eine Kette: Arbeitsverzeichnis zu Staging zu lokal zu Remote — jeder Pfeil bringt die Änderung einen Schritt näher daran, geteilt zu sein.
• Die Entscheidung „Zwei Personen haben dieselben Zeilen geändert?“ ist die einzige Verzweigung, und beide Ausgänge laufen am Ende in der geteilten Historie zusammen.

Bearbeiten und vormerken

„Entwickler bearbeitet Dateien im Arbeitsverzeichnis“ ist die noch nicht festgeschriebene Wirklichkeit — Dateien auf der Platte, noch nicht Teil der Historie. „git add verschiebt Änderungen in die Staging-Area“ ist der bewusste Zwischenschritt: Das Vormerken lässt Sie einen Commit aus ausgewählten Änderungen bauen statt aus allem, was Sie angefasst haben. Die Darstellung trennt beides in eigene Bahnengruppen, weil der zweistufige Commit Git seine Genauigkeit gibt.

Die Momentaufnahme festschreiben

„git commit macht eine Momentaufnahme der vorgemerkten Änderungen“ ist die Stelle, an der eine Änderung dauerhaft wird. „Git speichert den Commit mit einem Zeiger auf seinen Vorgänger“ macht den Graphen sichtbar — jeder Commit (außer dem ersten) nennt den Commit davor, und genau das macht die Historie nur-anfügend und prüfbar. „Der Branch-Zeiger rückt auf den neuen Commit“ schließt den Akt ab: Ein Branch ist nur ein Zeiger, auf einem Branch zu committen heißt also, diesen Zeiger zu bewegen. Den Commit selbst kümmert es nicht, auf welchem Branch er liegt.

Historie teilen

„git push sendet die Commits an das Remote“ führt aus der Bahnengruppe „Lokales Repository“ in die Bahnengruppe „Remote-Repository“ — die einzige Stelle, an der Daten Ihren Rechner verlassen. „Remote-Repository verzeichnet die neue Historie“ ist die geteilte Kopie, und „Zwei Personen haben dieselben Zeilen geändert?“ modelliert den Merge: Git führt auseinandergelaufene Historien automatisch zusammen, sofern nicht dieselben Zeilen bearbeitet wurden; in diesem Fall macht „Merge-Konflikt — Entwickler löst ihn von Hand“ die menschliche Entscheidung sichtbar, bevor „Historie ist geteilt und aktuell“ den Ablauf schließt.

Wichtige Zusammenhänge und Erkenntnisse

• Ein Commit ist eine vollständige Momentaufnahme, verbunden mit seinem Vorgänger, und genau das macht die Historie zu einem nur-anfügenden Graphen.
• Ein Branch ist ein Zeiger auf einen Commit, kein Behälter für Änderungen — deshalb kosten Anlegen und Wechseln von Branches fast nichts.
• Das Vormerken ist der bewusste Zwischenschritt, mit dem Sie wählen, was ein Commit enthält.
• Git ist verteilt: Alle halten die vollständige Historie lokal, und push und pull tauschen nur die fehlenden Teile aus.
• Konflikte sind die Ausnahme, nicht die Regel — und wenn sie auftreten, löst ein Mensch sie ausdrücklich auf.

Wann Sie diese Darstellung nutzen

• Einem Team das Modell der Momentaufnahme beibringen, das Git bisher nur als Folge von Befehlen kennt.
• Branches, Merges und Konflikte über das Zeigermodell erklären statt über auswendig gelernte Befehle.
• Eine Prüfung des Commit- und Branch-Vorgehens im Team daran ausrichten, wie die Historie wirklich aufgebaut ist.

So funktioniert es

1. Zeichnen Sie den echten Ablauf Ihres Teams nach

   Vermerken Sie an den Kästen die Befehle, die Ihr Team tatsächlich nutzt — Feature-Branches, Pull Requests, Rebase gegenüber Merge —, damit das Diagramm Ihre Praxis dokumentiert und nicht die eines Lehrbuchs.

2. Ergänzen Sie Ihr Branch-Modell

   Fügen Sie in die Bahnengruppe des lokalen Repositorys Zeilen für Feature-Branch und Main-Branch ein, und zeichnen Sie die Merge-Pfeile dazwischen, die in der geteilten Historie enden.

3. Zeichnen Sie die Freigabestufe des Pull Requests

   Ergänzen Sie zwischen dem lokalen Senden und dem Verzeichnen im Remote eine Entscheidung: eine Prüfung durch Kollegen und einen CI-Lauf, die bestehen müssen, bevor der Branch nach main zusammengeführt wird.

4. Ergänzen Sie die Wege zurück

   Nehmen Sie die Rückgängig-Zweige auf — einen Commit zurücknehmen, eine Nachricht ändern, auf einen früheren Stand zurücksetzen —, die jeweils in einem expliziten Ergebnis enden, denn die Rückwege sind die halbe Arbeit mit Git.

Häufig gestellte Fragen

Was ist Git, und wie unterscheidet es sich von anderer Versionsverwaltung?

Git ist eine verteilte Versionsverwaltung auf Basis von Momentaufnahmen. Jeder Commit speichert ein vollständiges Bild des Repositorys plus einen Zeiger auf seinen Vorgänger, nicht bloß eine Liste von Dateiänderungen. Weil jede Entwicklerin und jeder Entwickler die vollständige Historie lokal hat, funktionieren die meisten Operationen offline, und Zusammenarbeit heißt, Commits mit Remotes auszutauschen.

Was ist ein Branch in Git?

Ein Branch ist ein beweglicher Zeiger auf einen Commit. Wenn Sie auf einem Branch committen, rückt der Zeiger auf den neuen Commit; der Commit selbst weiß nicht, auf welchem Branch er liegt, und es ist ihm gleich. Deshalb ist das Anlegen eines Branches sofort erledigt, und deshalb ändert der Wechsel zwischen Branches nur, welche Momentaufnahme Ihr Arbeitsverzeichnis zeigt.

Warum hat Git eine Staging-Area?

Die Staging-Area lässt Sie einen Commit bewusst zusammenstellen. Sie können mehrere Dateien bearbeiten, nur die vormerken, die zusammengehören, und diese Auswahl committen — die übrige Arbeit bleibt außen vor. Arbeitsverzeichnis, Staging-Area und Repository sind drei getrennte Zustände, und genau diese Kette zeichnet die Darstellung.

Wie löst Git Merge-Konflikte auf?

Ändern zwei Branches verschiedene Dateien oder verschiedene Zeilen, führt Git sie automatisch zusammen. Ändern sie dieselben Zeilen, kann Git nicht erraten, welche Fassung richtig ist, markiert deshalb den Konflikt und bittet einen Menschen um die Wahl. Der Konflikt ist eine Entscheidung, kein Fehlschlag — deshalb leitet die Darstellung ihn zu einem ausdrücklichen Auflösungsschritt, bevor die Historie geteilt wird.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese Git-Zeichenfläche als eigenes Diagramm, benennen Sie die Bahnen auf Ihren Arbeitsablauf um, und zeichnen Sie Ihre eigene Historie nach.

Diese Darstellung in QueryChart (FlowJam) bearbeiten