So prüfen Sie, ob ein Git-Commit Vorfahr eines anderen ist

Einführung

In diesem Lab lernen Sie, wie Sie feststellen können, ob ein Git-Commit (Git-Eincheckung) Vorfahr eines anderen ist. Das Verständnis der Vorfahrbeziehungen zwischen Commits ist entscheidend, um sich in der Projektgeschichte zurechtzufinden und sie zu verstehen.

Wir werden uns das Kommando git merge-base --is-ancestor anschauen, ein leistungsstarkes Werkzeug für diesen Zweck. Darüber hinaus nutzen wir git log, um die Commit-Historie zu visualisieren und die Vorfahrbeziehungen nachzuverfolgen, und testen das Kommando mit Commits, die keine Vorfahren sind, um Ihr Verständnis zu festigen. Am Ende dieses Labs können Sie die Vorfahrbeziehungen in Ihrem Git-Repository sicher identifizieren.

Skills Graph

Verwenden von git merge-base --is-ancestor

In diesem Schritt lernen wir, wie man das Kommando git merge-base --is-ancestor verwendet, um festzustellen, ob ein Commit (Eincheckung) Vorfahr eines anderen ist. Dies ist ein grundlegendes Konzept für das Verständnis der Geschichte und der Beziehungen zwischen verschiedenen Versionen Ihres Projekts in Git.

Zunächst erstellen wir ein einfaches Git-Repository und machen ein paar Commits, um eine Historie aufzubauen. Navigieren Sie in Ihr Projektverzeichnis, falls Sie nicht bereits dort sind:

cd ~/project

Jetzt erstellen wir ein neues Verzeichnis für dieses Lab und initialisieren darin ein Git-Repository:

mkdir git-ancestor-lab
cd git-ancestor-lab
git init

Sie sollten eine Ausgabe ähnlich dieser sehen:

Initialized empty Git repository in /home/labex/project/git-ancestor-lab/.git/

Als Nächstes erstellen wir unsere erste Datei und committen sie:

echo "Initial content" > file1.txt
git add file1.txt
git commit -m "Add file1 with initial content"

Sie werden eine Ausgabe sehen, die den Commit bestätigt:

[master (root-commit) <commit-hash>] Add file1 with initial content
 1 file changed, 1 insertion(+)
 create mode 100644 file1.txt

Jetzt machen wir einen weiteren Commit. Ändern Sie die Datei und committen Sie die Änderungen:

echo "More content" >> file1.txt
git add file1.txt
git commit -m "Add more content to file1"

Sie werden eine Ausgabe sehen, die den zweiten Commit bestätigt:

[master <commit-hash>] Add more content to file1
 1 file changed, 1 insertion(+)

Wir haben jetzt eine einfache Historie mit zwei Commits. Schauen wir uns das Log an, um die Commit-Hashes zu sehen:

git log --oneline

Die Ausgabe wird in etwa so aussehen (Ihre Commit-Hashes werden unterschiedlich sein):

<commit-hash-2> (HEAD -> master) Add more content to file1
<commit-hash-1> Add file1 with initial content

In dieser Ausgabe ist <commit-hash-1> der Hash des ersten Commits und <commit-hash-2> der Hash des zweiten Commits. Der zweite Commit ist ein direkter Nachfolger des ersten Commits. Das bedeutet, dass der erste Commit Vorfahr des zweiten Commits ist.

Das Kommando git merge-base --is-ancestor <ancestor-commit> <descendant-commit> prüft, ob der erste Commit Vorfahr des zweiten Commits ist. Wenn dies der Fall ist, beendet das Kommando mit einem Status von 0 (Erfolg). Wenn nicht, beendet es mit einem Status von 1 (Fehler).

Lassen Sie uns dies testen. Ersetzen Sie <commit-hash-1> und <commit-hash-2> durch die tatsächlichen Hashes aus Ihrer git log --oneline-Ausgabe.

git merge-base --is-ancestor <commit-hash-1> <commit-hash-2>
echo $?

Das Kommando echo $? gibt den Exit-Status des vorherigen Kommandos aus. Da <commit-hash-1> Vorfahr von <commit-hash-2> ist, sollte das git merge-base-Kommando erfolgreich sein, und die Ausgabe von echo $? sollte 0 sein.

Das Verständnis von Vorfahrbeziehungen ist für viele Git-Operationen, wie z. B. Merging (Zusammenführen) und Rebasing (Neubasieren), von entscheidender Bedeutung, da es Git hilft, die gemeinsame Historie zwischen verschiedenen Branches (Zweigen) oder Commits zu bestimmen.

Ausführen von git log zur Verfolgung von Vorfahrbeziehungen

In diesem Schritt verwenden wir das Kommando git log, um die Commit-Historie zu visualisieren und das Konzept der Vorfahrbeziehungen deutlicher zu verstehen. Das git log-Kommando ist ein leistungsstarkes Werkzeug, um die Historie Ihres Repositorys zu erkunden.

Navigieren Sie in Ihr Repository-Verzeichnis, falls Sie nicht bereits dort sind:

cd ~/project/git-ancestor-lab

In unserem Repository haben wir bereits zwei Commits. Schauen wir uns das Log erneut an, diesmal im Standardformat:

git log

Die Ausgabe zeigt die Details jedes Commits, einschließlich des Commit-Hashes, des Autors, des Datums und der Commit-Nachricht. Die Commits werden in umgekehrter chronologischer Reihenfolge aufgelistet (neueste zuerst).

commit <commit-hash-2> (HEAD -> master)
Author: Jane Doe <[email protected]>
Date:   <Date and Time>

    Add more content to file1

commit <commit-hash-1>
Author: Jane Doe <[email protected]>
Date:   <Date and Time>

    Add file1 with initial content

In dieser Ausgabe können Sie sehen, dass der zweite Commit (<commit-hash-2>) auf den ersten Commit (<commit-hash-1>) verweist. So verfolgt Git die Historie. Jeder Commit (außer dem ersten) hat einen Eltern-Commit, und diese Eltern-Kind-Beziehung definiert die Vorfahrbeziehung.

Das git log-Kommando durchläuft im Wesentlichen diese Eltern-Kette rückwärts, beginnend mit dem aktuellen Commit (angezeigt durch HEAD -> master).

Fügen wir einen weiteren Commit hinzu, um die Historie etwas länger zu machen:

echo "Final content" >> file1.txt
git add file1.txt
git commit -m "Add final content to file1"

Jetzt führen wir git log --oneline erneut aus, um die aktualisierte Historie zu sehen:

git log --oneline

Die Ausgabe zeigt drei Commits:

<commit-hash-3> (HEAD -> master) Add final content to file1
<commit-hash-2> Add more content to file1
<commit-hash-1> Add file1 with initial content

Hier ist <commit-hash-3> der neueste Commit, <commit-hash-2> ist sein Eltern-Commit und <commit-hash-1> ist der Eltern-Commit von <commit-hash-2>. Das bedeutet, dass <commit-hash-1> Vorfahr sowohl von <commit-hash-2> als auch von <commit-hash-3> ist. Ebenso ist <commit-hash-2> Vorfahr von <commit-hash-3>.

Wir können git merge-base --is-ancestor verwenden, um diese Beziehungen zu überprüfen. Ersetzen Sie die Platzhalter durch Ihre tatsächlichen Commit-Hashes.

git merge-base --is-ancestor <commit-hash-1> <commit-hash-3>
echo $?

Dies sollte 0 ausgeben, da der erste Commit Vorfahr des dritten Commits ist.

git merge-base --is-ancestor <commit-hash-2> <commit-hash-3>
echo $?

Dies sollte ebenfalls 0 ausgeben, da der zweite Commit Vorfahr des dritten Commits ist.

Die Verwendung von git log hilft Ihnen, den Commit-Graphen zu visualisieren und die Eltern-Kind-Beziehungen zu verstehen, die direkt mit dem Konzept der Vorfahrbeziehungen zusammenhängen, das git merge-base --is-ancestor prüft.

Testen von Commits ohne Vorfahrbeziehung

In den vorherigen Schritten haben wir git merge-base --is-ancestor verwendet, um zu bestätigen, dass frühere Commits Vorfahren späterer Commits auf demselben Branch sind. Jetzt wollen wir untersuchen, was passiert, wenn wir Commits testen, die keine Vorfahren voneinander sind.

Navigieren Sie in Ihr Repository-Verzeichnis:

cd ~/project/git-ancestor-lab

Wir haben derzeit einen einzigen Branch (master) mit drei Commits. Um Beziehungen ohne Vorfahrbeziehung zu testen, müssen wir einen neuen Branch erstellen und einen Commit auf diesem Branch machen. Dies wird eine divergierende Historie schaffen.

Zunächst erstellen wir einen neuen Branch namens feature:

git branch feature

Dieser Befehl erstellt einen neuen Branch-Zeiger namens feature, der auf denselben Commit wie master zeigt (unser neuestes Commit, <commit-hash-3>).

Jetzt wechseln wir zum feature-Branch:

git checkout feature

Sie sollten eine Ausgabe sehen, die anzeigt, dass Sie den Branch gewechselt haben:

Switched to branch 'feature'

Wir befinden uns jetzt auf dem feature-Branch. Lassen Sie uns einen neuen Commit auf diesem Branch machen. Erstellen Sie eine neue Datei:

echo "Feature content" > file2.txt
git add file2.txt
git commit -m "Add file2 on feature branch"

Sie werden eine Ausgabe sehen, die den Commit auf dem feature-Branch bestätigt:

[feature <commit-hash-4>] Add file2 on feature branch
 1 file changed, 1 insertion(+)
 create mode 100644 file2.txt

Jetzt schauen wir uns die Historie mit git log --oneline --all --graph an. Die Option --all zeigt Commits von allen Branches an, und --graph zeichnet eine textbasierte Darstellung der Commit-Historie.

git log --oneline --all --graph

Die Ausgabe zeigt eine verzweigte Historie. Sie könnte in etwa so aussehen (die Commit-Hashes variieren):

* <commit-hash-4> (HEAD -> feature) Add file2 on feature branch
* <commit-hash-3> (master) Add final content to file1
* <commit-hash-2> Add more content to file1
* <commit-hash-1> Add file1 with initial content

In diesem Graphen ist <commit-hash-4> das neueste Commit auf dem feature-Branch, und <commit-hash-3> ist das neueste Commit auf dem master-Branch. Diese beiden Commits sind keine Vorfahren voneinander. Sie haben einen gemeinsamen Vorfahren, nämlich <commit-hash-3> (das Commit, an dem der feature-Branch erstellt wurde).

Lassen Sie uns git merge-base --is-ancestor verwenden, um die Beziehung zwischen <commit-hash-4> und <commit-hash-3> zu testen. Ersetzen Sie die Platzhalter durch Ihre tatsächlichen Commit-Hashes.

git merge-base --is-ancestor <commit-hash-4> <commit-hash-3>
echo $?

Dieser Befehl prüft, ob <commit-hash-4> Vorfahr von <commit-hash-3> ist. Basierend auf unserem Graphen ist dies nicht der Fall. Daher sollte der Befehl mit einem Status von 1 beenden.

Jetzt testen wir es umgekehrt: Ist <commit-hash-3> Vorfahr von <commit-hash-4>?

git merge-base --is-ancestor <commit-hash-3> <commit-hash-4>
echo $?

Dieser Befehl prüft, ob <commit-hash-3> Vorfahr von <commit-hash-4> ist. Betrachtet man den Graphen, ist der Eltern-Commit von <commit-hash-4> <commit-hash-3>. Also ist <commit-hash-3> tatsächlich Vorfahr von <commit-hash-4>. Der Befehl sollte mit einem Status von 0 beenden.

Dies zeigt, wie git merge-base --is-ancestor verwendet werden kann, um programmgesteuert die Beziehung zwischen zwei beliebigen Commits in der Historie Ihres Repositorys zu prüfen, auch über verschiedene Branches hinweg.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man das Kommando git merge-base --is-ancestor verwendet, um zu prüfen, ob ein Git-Commit Vorfahr eines anderen Commits ist. Wir haben begonnen, indem wir ein einfaches Git-Repository erstellt und einige Commits vorgenommen haben, um eine Historie aufzubauen. Anschließend haben wir git log --oneline verwendet, um die Commit-Historie anzuzeigen und die Commit-Hashes zu identifizieren. Dieser grundlegende Schritt ist entscheidend für das Verständnis der Beziehungen zwischen verschiedenen Versionen eines Projekts in Git.