Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Git stellt den Verlauf grundlegend anders dar als zentralisierte Versionssteuerungssysteme (CVCS), z. B. Team Foundation Version Control, Perforce oder Subversion. Zentrale Systeme speichern einen separaten Verlauf für jede Datei in einem Repository. Git speichert den Verlauf als Diagramm von Momentaufnahmen des gesamten Repositorys. Diese Momentaufnahmen, die in Git als Commits bezeichnet werden, können mehrere übergeordnete Elemente aufweisen und einen Verlauf erstellen, der wie ein Diagramm anstelle einer geraden 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 Verlaufsbeispiel: einem Repository mit drei linearen Commits.
Commit A ist das übergeordnete Element von Commit B, und commit B ist das übergeordnete Element von Commit C. Diese Geschichte ähnelt einem CVCS. Der Pfeil, der auf C zeigt, ist eine Verzweigung. Verzweigungen sind Zeiger auf bestimmte Commits, weshalb Verzweigungen in Git so leicht und einfach sind.
Ein wichtiger Unterschied in Git im Vergleich zu CVCS besteht darin, dass der Entwickler über eine eigene vollständige Kopie des Repositorys verfügt. Sie müssen ihr lokales Repository mit dem Remote-Repository synchronisieren, indem sie die neuesten Commits aus dem Remote-Repository abrufen. Dazu ziehen sie den Hauptzweig mit dem folgenden Befehl:
git pull origin main
Dadurch werden alle Änderungen aus dem Hauptzweig im Remote-Repository zusammengeführt, den Git standardmäßig als origin bezeichnet. Dieser Pull-Befehl brachte einen neuen Commit, und die Hauptverzweigung im lokalen Repository aktualisiert sich auf diesen Commit.
Verzweigungshistorie verstehen
Jetzt ist es an der Zeit, eine Änderung am Code vorzunehmen. Es ist üblich, mehrere aktive Branches zu haben, wenn man parallel an verschiedenen Features arbeitet. Dies steht in starkem Gegensatz zu CVCS, wo neue Zweige aufwendig sind und selten erstellt werden. Der erste Schritt besteht darin, mit dem folgenden Befehl auf einen neuen Branch zu wechseln:
git checkout -b cool-new-feature
Dies ist eine Tastenkombination, die zwei Befehle kombiniert:
-
git branch cool-new-featureso erstellen Sie die Verzweigung -
git checkout cool-new-featureum mit der Arbeit in der Zweigstelle zu beginnen
Zwei Verzweigungen zeigen nun auf denselben Commit. Angenommen, es gibt einige Änderungen am cool-new-feature Branch in zwei neuen Commits, E und F.
Die Commits sind vom cool-new-feature Branch erreichbar, da sie in diesen Branch committet wurden.
Nachdem das Feature fertiggestellt ist, muss es in den Hauptzweig zusammengeführt werden. Verwenden Sie dazu den folgenden Befehl:
git merge cool-new-feature main
Zusammenführen eines Branches
Die Graphenstruktur der Historie wird sichtbar, wenn eine Zusammenführung erfolgt. Git erstellt einen neuen Commit, wenn der Branch in einen anderen Branch integriert wird. Dies ist ein Zusammenführungs-Commit. Dieser Merge-Commit enthält keine Änderungen, da keine Konflikte vorhanden waren. Wenn Konflikte aufgetreten sind, würde der Zusammenführungs-Commit die erforderlichen Änderungen enthalten, um sie zu beheben.
Geschichte in der realen Welt
Hier sehen Sie ein Beispiel für den Git-Verlauf, der code in der aktiven Entwicklung in einem Team genauer ähnelt.
Es gibt drei Personen, die Zusammenführungen von ihren eigenen Filialen in die main Zweigstelle um die gleiche Zeit ausführen.
Nächste Schritte
Erfahren Sie mehr über das Arbeiten mit dem Git-Verlauf in GitHub und Azure Repos oder Git Log History Vereinfachung.