So prüfen Sie, ob ein Git-Branch verwaist ist

Einführung

In diesem Lab werden Sie lernen, wie Sie prüfen können, ob ein Git-Branch (Git-Zweig) ein Orphan-Branch (verwaister Zweig) ist. Wir werden den Befehl git log untersuchen, um Commits (Versionsänderungen) ohne Eltern-Commits zu verstehen, was für den ersten Commit in einem Repository (Versionsverwaltungsspeicher) charakteristisch ist.

Darüber hinaus werden Sie den Befehl git branch --no-merged nutzen, um Branches zu identifizieren, deren Änderungen noch nicht in den aktuellen Branch integriert wurden. Abschließend werden Sie diese Konzepte testen, indem Sie einen neuen Orphan-Branch erstellen und untersuchen.

Skills Graph

Prüfen des Git-Logs auf Commits ohne Eltern-Commits

In diesem Schritt werden wir den Befehl git log weiter untersuchen, insbesondere wie er in einem Repository mit Commits ohne Eltern-Commits verhält. Dies ist der Fall für den allerersten Commit in einem Repository.

Zunächst stellen Sie sicher, dass Sie sich im Verzeichnis my-time-machine befinden:

cd ~/project/my-time-machine

Nun verwenden wir den Befehl git log mit der Option --pretty=oneline. Diese Option zeigt jeden Commit in einer einzigen Zeile an, was für eine knappe Übersicht der Historie nützlich ist. Wir fügen auch die Option --max-count=1 hinzu, um nur den neuesten Commit anzuzeigen.

git log --pretty=oneline --max-count=1

Sie sollten eine Ausgabe ähnlich dieser sehen:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9 (HEAD -> master) Send a message to the future

Diese Ausgabe zeigt den Commit-Hash (die lange Zeichenkette), den Branch, auf dem sich der Commit befindet (HEAD -> master), und die Commit-Nachricht.

Nun versuchen wir, den Eltern-Commit dieses Commits anzuzeigen. Da dies der allererste Commit ist, hat er keinen Eltern-Commit. Wir können die Option --no-walk=parent mit git log verwenden, um zu versuchen, den Eltern-Commit anzuzeigen.

git log --no-walk=parent --pretty=oneline --max-count=1

Dieser Befehl wird wahrscheinlich keine Ausgabe liefern oder eine Fehlermeldung anzeigen, die darauf hinweist, dass es keinen Eltern-Commit zum Anzeigen gibt. Dies ist das erwartete Verhalten für den ersten Commit.

Das Verständnis, dass der erste Commit keinen Eltern-Commit hat, ist grundlegend für das Verständnis, wie Git seine Historie aufbaut. Jeder nachfolgende Commit wird einen oder mehrere Eltern-Commits haben und so eine Kette von Änderungen bilden.

Verwenden von git branch --no-merged

In diesem Schritt werden wir uns mit dem Befehl git branch und insbesondere der Option --no-merged befassen. Diese Option hilft uns, Branches (Zweige) zu identifizieren, die Änderungen enthalten, die noch nicht in den aktuellen Branch integriert wurden.

Zunächst erstellen wir einen neuen Branch. Stellen Sie sich einen Branch als eine alternative Zeitlinie vor, in der Sie an neuen Funktionen oder Experimenten arbeiten können, ohne die Hauptzeitlinie (master) zu beeinflussen.

Stellen Sie sicher, dass Sie sich im Verzeichnis ~/project/my-time-machine befinden.

cd ~/project/my-time-machine

Nun erstellen wir einen neuen Branch namens experiment:

git branch experiment

Dieser Befehl erstellt den neuen Branch, wechselt Sie aber nicht zu ihm. Sie befinden sich immer noch auf dem master-Branch.

Listen wir alle Branches in unserem Repository mit dem Befehl git branch auf:

git branch

Sie sollten eine Ausgabe ähnlich dieser sehen:

  experiment
* master

Das Sternchen (*) zeigt an, auf welchem Branch Sie sich derzeit befinden, in diesem Fall master.

Nun verwenden wir den Befehl git branch --no-merged. Dieser Befehl listet die Branches auf, die noch nicht in den aktuellen Branch (master) gemerged (zusammengeführt) wurden.

git branch --no-merged

Sie sollten Folgendes sehen:

  experiment

Diese Ausgabe sagt uns, dass der experiment-Branch Änderungen enthält, die im master-Branch nicht vorhanden sind. In diesem Fall, da wir den experiment-Branch gerade aus dem master-Branch erstellt haben und noch keine Änderungen daran vorgenommen haben, mag dies zunächst unintuitiv erscheinen. Die Option --no-merged ist jedoch so konzipiert, dass sie Branches anzeigt, deren Ende (tip) Commit nicht vom Ende des aktuellen Branches aus erreichbar ist. Da experiment derzeit auf denselben Commit wie master zeigt, aber master experiment noch nicht "gemerged" hat (was in diesem Kontext keinen Sinn macht), wird experiment dennoch aufgelistet.

In einer realen Anwendung würden Sie normalerweise einen neuen Branch erstellen, einige Commits darauf vornehmen und dann git branch --no-merged von Ihrem Hauptbranch (z. B. master) aus verwenden, um zu sehen, welche Feature-Branches bereit für die Merging sind.

Testen mit einem neuen Orphan-Branch

In diesem Schritt werden wir einen neuen "Orphan-Branch" (Verwaist-Zweig) erstellen. Ein Orphan-Branch ist ein Branch, der ohne Historie aus vorherigen Branches beginnt. Es ist wie das Starten einer völlig neuen Zeitlinie in Ihrer Zeitmaschine. Dies ist nützlich für Dinge wie Dokumentations-Branches oder gh-pages-Branches für Websites, bei denen Sie nicht möchten, dass die Historie Ihres Hauptcodes enthalten ist.

Stellen Sie sicher, dass Sie sich im Verzeichnis ~/project/my-time-machine befinden.

cd ~/project/my-time-machine

Nun erstellen wir einen neuen Orphan-Branch namens new-start:

git checkout --orphan new-start

Sie sollten eine Ausgabe ähnlich dieser sehen:

Switched to a new branch 'new-start'

Wir haben uns jetzt auf den new-start-Branch gewechselt. Beachten Sie, dass die Dateien aus dem master-Branch immer noch in Ihrem Arbeitsverzeichnis vorhanden sind. Dies liegt daran, dass git checkout --orphan Ihr Arbeitsverzeichnis und den Index für einen neuen Root-Commit (Stamm-Commit) vorbereitet, aber die vorhandenen Dateien nicht entfernt.

Lassen Sie uns den Status prüfen:

git status

Sie sollten etwas wie Folgendes sehen:

On branch new-start

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt

nothing added to commit but untracked files present (use "git add" to track)

Git sieht message.txt als eine nicht-verfolgte Datei an, da die Historie des new-start-Branches vollständig getrennt von master ist.

Um auf diesem Orphan-Branch wirklich neu anzufangen, entfernen wir normalerweise die alten Dateien und fügen dann den neuen Inhalt für diesen Branch hinzu. Lassen Sie uns die Datei message.txt entfernen:

rm message.txt

Nun prüfen wir erneut den Status:

git status

Sie sollten Folgendes sehen:

On branch new-start

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Das Arbeitsverzeichnis ist jetzt sauber, und wir sind bereit, den ersten Commit auf unserer neuen, unabhängigen Zeitlinie zu erstellen.

Lassen Sie uns eine neue Datei erstellen, die speziell für diesen Branch ist:

echo "This is a fresh start!" > readme.md

Fügen Sie die neue Datei in die Staging-Area (Zwischenspeicher) ein:

git add readme.md

Und schließlich erstellen wir den ersten Commit auf dem new-start-Branch:

git commit -m "Initial commit for new-start branch"

Sie sollten eine Ausgabe ähnlich dieser sehen:

[new-start (root-commit) a1b2c3d] Initial commit for new-start branch
 1 file changed, 1 insertion(+)
 create mode 100644 readme.md

Beachten Sie, dass dieser Commit auch ein "(root-commit)" ist, genau wie der erste Commit auf dem master-Branch. Dies bestätigt, dass er keinen Eltern-Commit hat und der Beginn einer neuen Historie ist.

Nun schauen wir uns das Log für diesen Branch an:

git log --pretty=oneline

Sie sollten nur den einzigen Commit sehen, den wir gerade gemacht haben:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9 (HEAD -> new-start) Initial commit for new-start branch

Dies zeigt, dass der new-start-Branch seine eigene unabhängige Historie hat, getrennt vom master-Branch.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Branch (Zweig) verwaist (orphaned) ist. Wir haben zunächst den Befehl git log untersucht, insbesondere wie man mithilfe von --no-walk=parent die Abwesenheit eines Eltern-Commits für den ersten Commit in einem Repository feststellen kann. Dies hat das grundlegende Konzept der Git-Historie gezeigt, bei dem der erste Commit keinen Eltern-Commit hat.

Anschließend wurden wir mit dem Befehl git branch --no-merged vertraut gemacht. Dieser Befehl wird verwendet, um Branches aufzulisten, die noch nicht in den aktuellen Branch gemerged (zusammengeführt) wurden. Dies ist eine Schlüsseltechnik, um Branches zu identifizieren, die möglicherweise verwaist sind oder unintegrierte Änderungen enthalten. Das Lab umfasste auch einen Schritt, um diese Konzepte zu testen, indem ein neuer Orphan-Branch erstellt und untersucht wurde.