So prüfen Sie, ob ein Git-Branch ungesendete Commits hat

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob Ihr lokaler Git-Branch Commits enthält, die noch nicht in ein Remote-Repository gepusht wurden. Wir werden verschiedene Methoden untersuchen, um diese nicht gepushten Commits zu identifizieren, beginnend mit dem Befehl git status, um zu sehen, ob Ihr Branch dem Remote-Branch vorauseilt.

Anschließend lernen Sie, wie Sie den Befehl git log mit bestimmten Argumenten verwenden, um die Commits aufzulisten, die lokal vorhanden sind, aber nicht auf dem Remote-Tracking-Branch. Schließlich besprechen wir, wie Sie diese Informationen verifizieren können, indem Sie Ihren lokalen Branch mit dem Remote-Repository vergleichen. Am Ende dieses Labs verfügen Sie über die Fähigkeiten, um einfach festzustellen, ob Ihre lokalen Änderungen gepusht werden müssen.

Skills Graph

Verwenden von git status zur Prüfung auf vorauseilende Commits

In diesem Schritt lernen wir, wie wir den Befehl git status verwenden können, um festzustellen, ob unser lokaler Branch Commits enthält, die dem Remote-Branch vorauseilen. Dies ist ein häufiges Szenario, wenn Sie lokal Änderungen vorgenommen haben, diese aber noch nicht in ein Remote-Repository gepusht haben.

Zunächst stellen wir sicher, dass wir uns im Projektverzeichnis befinden. Öffnen Sie Ihr Terminal und navigieren Sie zum Verzeichnis my-time-machine:

cd ~/project/my-time-machine

Jetzt erstellen wir eine neue Datei und fügen ihr etwas Inhalt hinzu. Wir nennen diese Datei future_plans.txt:

echo "Plan for world domination." > future_plans.txt

Als Nächstes müssen wir diese neue Datei für einen Commit vorbereiten (stagen):

git add future_plans.txt

Jetzt erstellen wir einen Commit mit einer Nachricht, die unsere Änderung beschreibt:

git commit -m "Add future plans"

Sie sollten eine Ausgabe ähnlich der folgenden sehen, die darauf hinweist, dass ein neuer Commit erstellt wurde:

[master abcdefg] Add future plans
 1 file changed, 1 insertion(+)
 create mode 100644 future_plans.txt

Wir haben nun einen neuen Commit auf unserem lokalen master-Branch erstellt. Dieser Commit existiert jedoch nur lokal und wurde noch nicht an ein Remote-Repository gesendet.

Verwenden wir git status, um den aktuellen Zustand unseres Repositorys zu sehen:

git status

Die Ausgabe sollte nun anzeigen, dass Ihr lokaler Branch dem Remote-Branch vorauseilt (wenn Sie einen konfiguriert hätten, was wir in diesem einfachen Beispiel nicht tun, aber Git gibt Ihnen dennoch den Hinweis):

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   future_plans.txt

nothing to commit, working tree clean

Die wichtige Zeile hier ist Your branch is ahead of 'origin/master' by 1 commit.. Dies sagt uns, dass unser lokaler master-Branch einen Commit enthält, der nicht auf dem origin/master-Branch (der Standardname für den Remote-Branch, den Git erwartet) vorhanden ist.

Dies ist eine sehr nützliche Information. Sie lässt Sie wissen, dass Sie lokale Änderungen haben, die noch nicht mit anderen geteilt wurden. In einem realen Szenario mit einem Remote-Repository würde dies darauf hinweisen, dass Sie Ihre Änderungen mit git push übertragen müssen.

Ausführen von git log --oneline @{u}..HEAD

Im vorherigen Schritt haben wir gesehen, wie git status uns mitteilen kann, ob unser lokaler Branch dem Remote-Branch vorauseilt. Jetzt verwenden wir den Befehl git log mit einer speziellen Syntax, um genau zu sehen, welche Commits vorauseilen.

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

Der Befehl, den wir verwenden werden, ist git log --oneline @{u}..HEAD. Lassen Sie uns diesen Befehl zerlegen:

• git log: Dies ist der Befehl, um die Commit-Historie anzuzeigen.
• --oneline: Diese Option zeigt jeden Commit in einer einzigen Zeile an, wodurch die Ausgabe kompakt und leicht lesbar wird.
• @{u}: Dies ist eine spezielle Syntax, die sich auf den Upstream-Branch bezieht. In unserem Fall, da wir keinen Upstream-Branch explizit festgelegt haben, nimmt Git standardmäßig origin/master an (unter der Annahme, dass origin der Name des Remotes und master der Branch ist).
• ..HEAD: Dies ist eine Bereichsnotation. HEAD bezieht sich auf die Spitze des aktuellen Branches (unser lokaler master). Der Bereich @{u}..HEAD bedeutet "zeige mir die Commits, die von HEAD erreichbar, aber nicht von @{u} erreichbar sind". Einfacher ausgedrückt, zeigt es die Commits an, die sich auf unserem lokalen Branch, aber nicht auf dem Upstream-Remote-Branch befinden.

Jetzt führen wir den Befehl aus:

git log --oneline @{u}..HEAD

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

abcdefg (HEAD -> master) Add future plans

Diese Ausgabe zeigt den Commit, den wir im vorherigen Schritt erstellt haben (Add future plans). Der eindeutige Bezeichner (abcdefg) wird in Ihrem Terminal anders sein, aber die Commit-Nachricht sollte übereinstimmen.

Dieser Befehl ist unglaublich nützlich, um genau zu sehen, welche Commits Sie in ein Remote-Repository pushen möchten. Er gibt Ihnen eine klare Liste der lokalen Änderungen, die noch nicht geteilt wurden.

Wenn Sie diese Ausgabe mit der git status-Ausgabe aus dem vorherigen Schritt vergleichen, können Sie sehen, dass git status Ihnen mitteilt, wie viele Commits Sie vorauseilen, während git log @{u}..HEAD Ihnen mitteilt, welche spezifischen Commits Sie vorauseilen lassen. Beide Befehle liefern wertvolle Informationen über den Zustand Ihres lokalen Repositorys im Vergleich zu seinem Remote-Gegenstück.

Überprüfung durch Vergleich mit Remote

In einem realen Szenario haben Sie normalerweise ein Remote-Repository (z. B. auf GitHub, GitLab oder Bitbucket), mit dem Ihr lokales Repository verbunden ist. In dieser Lab-Umgebung haben wir kein aktives Remote-Repository, an das wir pushen können. Wir können jedoch das Konzept des Vergleichs unseres lokalen Branches mit einem Remote-Branch mithilfe der von uns gelernten Befehle simulieren.

Wir haben bereits git status und git log --oneline @{u}..HEAD verwendet, um die Commits zu sehen, die sich auf unserem lokalen Branch, aber nicht auf dem simulierten Upstream-Branch (origin/master) befinden.

Lassen Sie uns die Ausgabe von git status erneut überprüfen:

git status

Sie sollten immer noch die Zeile sehen, die darauf hinweist, dass Ihr Branch vorauseilt:

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

... (rest of the output)

Und die Ausgabe von git log --oneline @{u}..HEAD:

git log --oneline @{u}..HEAD

Dies sollte den einzigen Commit anzeigen, den wir gemacht haben:

abcdefg (HEAD -> master) Add future plans

Diese beiden Befehle arbeiten zusammen, um Ihnen ein klares Bild des Unterschieds zwischen Ihrem lokalen Branch und seinem konfigurierten Upstream-Branch zu geben. git status liefert eine Zusammenfassung, während git log @{u}..HEAD die Details der spezifischen Commits liefert.

In einem realen Projekt würden Sie nach dem Sehen dieser Ausgabe normalerweise git push ausführen, um Ihre lokalen Commits an das Remote-Repository zu senden, damit sie für andere verfügbar sind und der Remote-Branch aktualisiert wird.

Da wir in diesem Lab kein Remote-Repository haben, an das wir pushen können, haben wir erfolgreich das Ziel erreicht, zu verstehen, wie man mit git status und git log Commits identifiziert, die dem Remote-Branch vorauseilen.

Diese Fähigkeit ist grundlegend für die Zusammenarbeit mit anderen und die Synchronisierung Ihrer lokalen und Remote-Repositories. Indem Sie regelmäßig den Status und die Logs prüfen, können Sie sich über Ihre ausstehenden Änderungen informiert halten und sicherstellen, dass Sie sie pushen, wenn Sie bereit sind.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Branch ungesendete Commits hat. Wir haben begonnen, indem wir nach einem lokalen Commit den Befehl git status verwendet haben. Die Ausgabe von git status zeigt klar an, ob der lokale Branch seinem Remote-Gegenstück "vorauseilt" und um wie viele Commits, was einen direkten Weg bietet, um zu sehen, ob es ungesendete Änderungen gibt.

Anschließend haben wir untersucht, wie man git log --oneline @{u}..HEAD verwendet, um eine detailliertere Ansicht der spezifischen Commits zu erhalten, die sich auf dem lokalen Branch, aber nicht auf dem Remote-Tracking-Branch befinden. Dieser Befehl listet die Commit-Hashes und -Nachrichten der ungesendeten Commits auf und bietet eine genaue Möglichkeit, zu identifizieren, welche Änderungen ausstehen. Schließlich haben wir das Konzept der Überprüfung durch Vergleich der lokalen und Remote-Branches diskutiert, um das Verständnis davon zu festigen, wie man das Vorhandensein ungesendeter Commits bestätigen kann.