Grundlegendes zum Git-Verlauf

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Git speichert den Verlauf als Diagramm von Momentaufnahmen – sogenannten Commits – des gesamten Repositorys. Jeder Commit enthält auch einen Zeiger auf einen oder mehrere vorherige Commits. Commits können mehrere übergeordnete Elemente aufweisen, was einen Verlauf ergibt, der wie ein Diagramm aussieht, anstatt wie eine gerade Linie. Dieser Unterschied im Verlauf ist von extremer Bedeutung und der Hauptgrund, warum Benutzer Git verwirrend finden.

Hinweis

Wenn Sie keine Änderung in Ihrem Git-Verlauf finden, von der Sie wissen, dass Sie sie vorgenommen haben, erfahren Sie mehr darüber, wie die Vereinfachung des Git-Verlaufs funktioniert, unter Git hat meine Änderungen verloren: Grundlegendes zur Vereinfachung des Git-Verlaufs.

Grundlagen des Commitverlaufs

Beginnen Sie mit einem einfachen Verlaufsbeispiel: einem Repository mit 3 linearen Commits.

Commit A ist das übergeordnete Element von Commit B, und Commit B ist das übergeordnete Element von Commit C. Dieser Verlauf ähnelt sehr einem CVCS. Der Pfeil, der auf Commit C zeigt, ist ein Branch. Sein Name lautet main, weil dies der Standardname für den Branch der Hauptlinie in einem Git-Repository ist. Branches sind Zeiger auf bestimmte Commits, weshalb Branching in Git so schlank und einfach ist.

Ein wichtiger Unterschied in Git im Vergleich zu einem CVCS ist, dass ich über meine eigene vollständige Kopie des Repositorys verfüge. Ich muss mein lokales Repository mit dem Remoterepository synchronisiert halten, indem ich die neuesten Commits aus dem Remoterepository abrufe. Hierzu pulle ich den Mainbranch mit dem folgenden Befehl:

git pull origin main

Dadurch werden alle Commits aus dem main Branch des Remoterepositorys (standardmäßig als origin bezeichnet) in den mainbranch des lokalen Repositorys kopiert („gepullt“). Der Pullvorgang hat einen neuen Commit kopiert, und der mainbranch im lokalen Repository zeigt nun auf diesen neuen Commit.

Grundlegendes zum Branchverlauf

Nun möchte ich eine Änderung an meinem Code vornehmen. Es ist üblich, mehrere aktive Branches zu haben, in denen Sie parallel an verschiedenen Features arbeiten. Dies steht im starken Gegensatz zum CVCS, wo neue Branches gewichtig sind und selten erstellt werden. Der erste Schritt besteht im Auschecken eines neuen Branchs mit dem folgenden Befehl:

git checkout -b cool-new-feature

Dies ist eine Kurzform, die zwei Befehle kombiniert: git branch cool-new-feature zum Erstellen des Branchs, gefolgt von git checkout cool-new-feature, um mit der Arbeit in dem Branch zu beginnen.

Zwei Branches zeigen nun auf denselben Commit. Ich nehme ein paar Änderungen am cool-new-feature-Branch mit zwei neuen Commits vor, nämlich E und F.

Meine Commits sind über den cool-new-feature-Branch erreichbar, da ich sie in diesem Branch vorgenommen habe. Ich bin mit meinem Feature fertig und möchte es in main zusammenführen. Hierzu verwende ich den folgenden Befehl:

git merge cool-feature main

Die Diagrammstruktur des Verlaufs wird sichtbar, wenn es zu einer Zusammenführung (Merge) kommt. Git erstellt einen neuen Commit, wenn ich meinen Branch in einen anderen Branch zusammengeführt habe. Dies ist ein Mergecommit. Dieser Mergecommit enthält keine Änderungen, da keine Konflikte vorlagen. Träten Konflikte auf, enthielte der Mergecommit die Änderungen, die zum Lösen dieser Konflikte erforderlich wären.

Verlauf in der Praxis

Hier sehen Sie ein Beispiel für den Git-Verlauf, das einem Code in der aktiven Entwicklung in einem Team ähnlicher ist. Es gibt drei Personen, die Commits aus ihren eigenen Branches ungefähr zur selben Zeit in den Mainbranch zusammenführen.

Nachdem Sie nun wissen, wie Branches und Zusammenführungen die Form des Diagramms bedingen und beeinflussen, sollte dies nicht mehr zu abschreckend sein.