So prüfen Sie, ob ein Git-Repository mit dem Remote-Repository synchronisiert ist

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob Ihr lokales Git-Repository mit seinem Remote-Repository synchronisiert ist. Wir werden praktische Methoden untersuchen, um festzustellen, ob Ihr lokaler Branch aktuell ist, hinter dem Remote-Branch zurückliegt oder ihm voraus ist.

Das Lab führt Sie durch das Abrufen von Änderungen aus einem Remote-Repository und die Verwendung von git status, um den Synchronisationszustand zu bewerten. Sie werden auch lernen, wie Sie git log verwenden, um Ihren lokalen HEAD mit dem Remote-Tracking-Branch (@{u}) zu vergleichen, um Unterschiede im Commit-Verlauf zu identifizieren. Abschließend werden wir den Zustand von Repositories simulieren und untersuchen, die auseinandergewachsen sind, um ein umfassendes Verständnis davon zu vermitteln, wie man Synchronisationsprobleme in Git erkennt und bewältigt.

Skills Graph

Abrufen und Prüfen des Git-Status

In diesem Schritt lernen wir, wie man Änderungen aus einem Remote-Repository abruft und den Status unseres lokalen Repositories prüft.

Stellen Sie sich vor, Sie arbeiten an einem Projekt mit anderen. Sie könnten Änderungen am Projekt vornehmen und diese an einem zentralen Ort (einem Remote-Repository) speichern. Sie müssen eine Möglichkeit haben, diese Änderungen in Ihre eigene Kopie des Projekts (Ihr lokales Repository) zu übertragen. Hier kommt git fetch ins Spiel.

Zunächst stellen wir sicher, dass wir uns im Projektverzeichnis befinden. Öffnen Sie Ihr Terminal und geben Sie ein:

cd ~/project/my-time-machine

Jetzt simulieren wir das Vorhandensein eines Remote-Repositories. In einer realen Situation würde dies auf einer Plattform wie GitHub oder GitLab liegen. Für dieses Lab verwenden wir ein lokales Verzeichnis als unser "Remote".

git remote add origin ../my-time-machine-remote

Dieser Befehl fügt ein "Remote" namens origin hinzu, das auf ein Verzeichnis außerhalb unseres aktuellen Projekts zeigt.

Jetzt verwenden wir git fetch, um alle Änderungen aus diesem simulierten Remote-Repository abzurufen.

git fetch origin

Sie sehen möglicherweise keine große Ausgabe, wenn es keine neuen Änderungen gibt. Aber dieser Befehl hat das Remote-Repository kontaktiert und alle neuen Informationen, wie z. B. Commits und Branches, heruntergeladen, ohne sie in Ihren aktuellen Branch zu mergen.

Nach dem Abrufen ist es immer eine gute Idee, den Status Ihres lokalen Repositories zu prüfen, um zu sehen, ob es Änderungen aus dem Remote-Repository gibt, die Sie noch nicht übernommen haben.

git status

Die Ausgabe von git status sagt Ihnen nun, ob Ihr lokaler Branch mit dem Remote-Branch "aktuell" ist oder ob es Änderungen gibt, die abgerufen werden können. Beispielsweise könnten Sie etwas wie Folgendes sehen:

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Oder, wenn es Änderungen im Remote-Repository gab:

On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

Das Verständnis der Ausgabe von git status nach einem git fetch ist von entscheidender Bedeutung. Es zeigt Ihnen die Beziehung zwischen Ihrem lokalen Branch und dem entsprechenden Branch im Remote-Repository. Dies hilft Ihnen zu entscheiden, ob Sie Änderungen abrufen müssen oder ob Ihre lokale Kopie bereits aktuell ist.

Verwenden von git log zum Vergleichen von HEAD und @{u}

In diesem Schritt verwenden wir den Befehl git log, um den Zustand unseres lokalen Branches (HEAD) mit seinem Upstream-Branch (@{u}) zu vergleichen. Dies ist eine leistungsstarke Methode, um die Unterschiede nach dem Abrufen von Änderungen zu visualisieren.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/my-time-machine

In Git bezieht sich HEAD auf den Commit, auf den Ihr aktueller Branch zeigt. Es repräsentiert die Spitze Ihrer aktuellen Arbeit. @{u} (oder @\{upstream\}) bezieht sich auf den Upstream-Branch, den Ihr aktueller lokaler Branch verfolgt. Dies ist typischerweise der entsprechende Branch im Remote-Repository, von dem Sie abgerufen haben.

Um die Commits anzuzeigen, die sich in Ihrem lokalen Branch (HEAD), aber nicht im Upstream-Branch (@{u}) befinden, können Sie den folgenden Befehl verwenden:

git log HEAD..@{u}

Dieser Befehl zeigt die Commits an, die von @{u} erreichbar, aber nicht von HEAD sind. Mit anderen Worten, es zeigt Commits, die sich auf dem Remote-Branch, aber noch nicht auf Ihrem lokalen Branch befinden. Wenn es keine solchen Commits gibt (was bedeutet, dass Ihr lokaler Branch aktuell oder voraus ist), wird dieser Befehl keine Ausgabe liefern.

Jetzt lassen Sie uns die Commits anzeigen, die sich im Upstream-Branch (@{u}), aber nicht in Ihrem lokalen Branch (HEAD) befinden. Dies zeigt Commits, die sich auf Ihrem lokalen Branch befinden, aber noch nicht an das Remote-Repository gepusht wurden.

git log @{u}..HEAD

Dieser Befehl zeigt die Commits an, die von HEAD erreichbar, aber nicht von @{u} sind. Wenn es keine solchen Commits gibt (was bedeutet, dass Ihr lokaler Branch aktuell oder hinterher ist), wird dieser Befehl keine Ausgabe liefern.

Durch die Verwendung von git log mit der ..-Notation können Sie einfach die Historie von zwei verschiedenen Punkten in Ihrem Repository vergleichen, wie z. B. Ihren lokalen Branch und seinen Upstream-Gegenpart. Dies ist unglaublich nützlich, um den Zustand Ihres Repositories im Vergleich zum Remote-Repository zu verstehen und um sich auf das Abrufen oder Pushen von Änderungen vorzubereiten.

Testen von divergierten Repositories

In diesem Schritt werden wir ein Szenario simulieren, in dem sowohl Ihr lokales Repository als auch das Remote-Repository neue Commits haben, die das jeweils andere Repository nicht hat. Dies wird als "divergierter" Zustand bezeichnet.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/my-time-machine

Erstellen wir nun einen neuen Commit in unserem lokalen Repository:

echo "Adding a local change" > local_change.txt
git add local_change.txt
git commit -m "Add a local change"

Jetzt simulieren wir einen Commit, der direkt im "Remote"-Repository vorgenommen wird. Wir wechseln in das Remote-Verzeichnis, erstellen einen Commit und wechseln dann zurück.

cd ../my-time-machine-remote
echo "Adding a remote change" > remote_change.txt
git add remote_change.txt
git commit -m "Add a remote change"
cd ../my-time-machine

Wir haben nun einen Commit in unserem lokalen Repository und einen separaten Commit im simulierten Remote-Repository erstellt. Unsere Repositories sind nun divergiert.

Lassen Sie uns erneut git fetch verwenden, um unsere Kenntnisse über das Remote-Repository zu aktualisieren:

git fetch origin

Jetzt prüfen wir den Status Ihres lokalen Repositories:

git status

Sie sollten eine Ausgabe sehen, die darauf hinweist, dass Ihr Branch divergiert ist. Etwa so:

On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

Diese Statusmeldung sagt Ihnen, dass sowohl Ihr lokaler Branch (master) als auch der Remote-Tracking-Branch (origin/master) seit dem letzten Mal, als sie synchron waren, mit neuen Commits weitergekommen sind. Sie schlägt sogar vor, git pull zu verwenden, um die Remote-Änderungen zu mergen.

Das Verständnis des divergierten Zustands ist wichtig, da es sich um ein häufiges Szenario bei der Zusammenarbeit mit anderen handelt. Es bedeutet, dass Sie die Remote-Änderungen in Ihren lokalen Branch integrieren müssen, bevor Sie Ihre eigenen Änderungen pushen können.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein lokales Git-Repository mit seinem Remote-Gegenstück synchronisiert ist. Wir haben begonnen, indem wir ein Remote-Repository simuliert und es mit git remote add zu unserem lokalen Projekt hinzugefügt haben. Der entscheidende Schritt, die Änderungen vom Remote-Repository abzurufen, ohne sie zu mergen, wurde mit git fetch origin durchgeführt. Nach dem Abruf haben wir git status verwendet, um den Synchronisationszustand unseres lokalen Branches im Vergleich zum Remote-Branch zu bestimmen und haben eine Ausgabe beobachtet, die anzeigt, ob der Branch aktuell ist oder hinterher liegt.

Wir werden weiterhin Methoden zur Vergleichung des lokalen HEAD mit dem Remote-Tracking-Branch mithilfe von git log untersuchen und Szenarien mit divergierten Repositories betrachten, um ein umfassendes Verständnis der Repository-Synchronisation zu erlangen.