Grundlegendes zum Git-Verlauf

Git stellt die Historie auf eine grundlegend andere Weise dar als zentralisierte Versionskontrollsysteme (CVCS) wie Team Foundation Version Control, Perforce oder Subversion. Zentralisierte Systeme speichern einen separaten Verlauf für jede Datei in einem Repository. Git speichert die Historie als Diagramm von Schnappschüssen des gesamten Repositorys. Diese Schnappschüsse, die in Git Commits genannt werden, können mehrere Elternteile haben, wodurch eine Historie entsteht, die wie ein Diagramm und nicht wie eine gerade Linie aussieht. Dieser Unterschied in der Geschichte ist unglaublich wichtig und ist der Hauptgrund, warum Benutzer, die mit CVCS vertraut sind, Git verwirrend finden.

Grundlagen des Commitverlaufs

Beginnen Sie mit einem einfachen Beispiel für den Verlauf: ein Repository mit drei linearen Übertragungen.

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. Branches sind Zeiger auf bestimmte Commits, weshalb Branching in Git so schlank und einfach ist.

Ein wesentlicher Unterschied zwischen Git und CVCS besteht darin, dass der Entwickler seine eigene vollständige Kopie des Repositorys besitzt. Sie müssen ihr lokales Repository mit dem entfernten Repository synchronisieren, indem sie die neuesten Commits aus dem entfernten Repository abrufen. Dazu ziehen sie den Hauptzweig mit dem folgenden Befehl:

git pull origin main

Damit werden alle Änderungen aus dem Hauptzweig im entfernten Repository zusammengeführt, das Git standardmäßig origin nennt. Dieser Pull brachte einen neuen Commit und der Hauptzweig im lokalen Repository wird auf diesen Commit verschoben.

Grundlegendes zum Branchverlauf

Nun ist es an der Zeit, eine Änderung am Code vorzunehmen. Es ist üblich, mehrere aktive Zweige zu haben, wenn man parallel an verschiedenen Funktionen arbeitet. 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 Abkürzung, die zwei Befehle kombiniert:

• git branch cool-new-feature um die Verzweigung zu erstellen
• git checkout cool-new-feature die Arbeit in der Filiale aufzunehmen

Zwei Branches zeigen nun auf denselben Commit. Angenommen, es gibt ein paar Änderungen auf dem cool-new-feature Zweig in zwei neuen Commits, E und F.

Die Übertragungen sind über den Zweig cool-new-feature erreichbar, da sie in diesen Zweig übertragen wurden. Jetzt, wo das Feature fertig ist, muss es in den Hauptzweig eingefügt werden. Verwenden Sie dazu den folgenden Befehl:

git merge cool-new-feature main

Die Diagrammstruktur des Verlaufs wird sichtbar, wenn es zu einer Zusammenführung (Merge) kommt. Git erstellt eine neue Übergabe, wenn der Zweig mit einem anderen Zweig zusammengeführt wird. Dies ist ein Mergecommit. Dieser Merge Commit enthält keine Änderungen, da es keine Konflikte gab. Im Falle von Konflikten würde der Merge-Commit die notwendigen Änderungen enthalten, um diese zu lösen.

Verlauf in der Praxis

Hier ist ein Beispiel für einen Git-Verlauf, der dem Code in der aktiven Entwicklung in einem Team ähnlicher ist. Es gibt drei Personen, die etwa zur gleichen Zeit Commits aus ihren eigenen Zweigen in den Zweig main einbringen.

Nächste Schritte

Erfahren Sie mehr über die Arbeit mit dem Git-Verlauf in GitHub und Azure Repos oder Vereinfachung des Git-Protokollverlaufs.