0%

Zusammenführen und Konflikte

Wann ein Merge einen Commit braucht

Ein Fast-Forward funktioniert, wenn ein Branch auf demselben Weg lediglich weiter voraus ist. Manchmal haben sich nach der Trennung beide Branches bewegt. Dann müssen zwei Entwicklungslinien erhalten bleiben.

Zwei Linien brauchen eine Verbindung

Stell dir vor, beide Branches begannen bei Commit B. Danach erstellte main Commit C, während simplify-tiers Commit D erstellte:

          C  main
         /
A -> B
         \
          D  simplify-tiers

Würde main direkt auf D verschoben, fiele C aus seinem Verlauf heraus. Würde es nirgends hin verschoben, fehlte D. Git erstellt stattdessen einen neuen Commit, der die beiden Verläufe verbindet:

          C ----\
         /       M  main
A -> B          /
         \     /
          D ---   simplify-tiers

Der neue Commit M ist ein Merge-Commit. Ein gewöhnlicher Commit hat einen Vorgänger: den Commit unmittelbar davor. Ein echter Merge-Commit hat zwei Vorgänger: den bisherigen letzten Commit des aktuellen Branchs und den letzten Commit des aufgenommenen Branchs.

Ihre Reihenfolge hält die Richtung fest. Wenn main aktuell ist, bildet sein bisheriger letzter Commit den ersten Vorgänger. Der letzte Commit von simplify-tiers ist der zweite. Beide bleiben Teil des erreichbaren Verlaufs. Der Merge verwirft also keine der beiden Entwicklungslinien.

Auch ein Merge-Commit ist eine Momentaufnahme

Der Merge-Commit zeichnet genau wie jeder andere Commit eine vollständige Momentaufnahme des Projekts auf. Er unterscheidet sich nicht durch eine besondere Art der Dateispeicherung. Sein Unterschied sind die beiden Verknüpfungen zu Vorgängern, die sagen: „Hier treffen sich diese beiden Linien.“

Wenn die Branches unterschiedliche Dateien oder unterschiedliche Teile einer Datei geändert haben, kann Git diese Momentaufnahme meist ohne Hilfe erstellen. Es führt die Änderungen zusammen und erstellt den Merge-Commit.

Wenn beide Branches dieselben Zeilen unterschiedlich geändert haben, kann Git nicht wissen, welchen endgültigen Text du beabsichtigst. Es hält vor dem Commit an und bittet dich um eine Entscheidung. Dieser Halt heißt Merge-Konflikt. Der Commit mit zwei Vorgängern wurde noch nicht erstellt, aber beide Vorgänger und die gesamte Arbeit sind weiterhin verfügbar.

Was unterscheidet einen echten Merge-Commit von einem gewöhnlichen Commit?

Beide Branches haben dieselben Zeilen unterschiedlich geändert. Was tut Git, wenn es das beabsichtigte Ergebnis nicht auswählen kann?

Das vorbereitete Repository steht genau an diesem Haltepunkt. Als Nächstes liest du seinen Zustand, siehst dir die Markierung der Alternativen an und lernst den sicheren Rückweg, falls du noch nicht entscheiden möchtest.