So prüfen Sie, ob ein Git-Remote neue Commits hat

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob ein Git-Remoterepository neue Commits enthält, die noch nicht in Ihrem lokalen Repository vorhanden sind. Dies ist eine entscheidende Fähigkeit für die kollaborative Entwicklung, da Sie so auf dem Laufenden bleiben können, was andere geändert haben.

Wir beginnen damit, ein Remoterepository zu simulieren und es zu unserem lokalen Projekt hinzuzufügen. Anschließend verwenden wir den Befehl git fetch, um Informationen über die Branches und Commits des Remotes abzurufen, ohne sie zu mergen. Abschließend untersuchen wir, wie Sie Ihren lokalen Branch mit seinem Upstream-Gegenstück vergleichen können, um eventuelle neue Commits auf dem Remote zu identifizieren.

Skills Graph

Abrufen von Remote-Änderungen mit git fetch

In diesem Schritt lernen wir, wie man Änderungen aus einem Remoterepository abruft. Stellen Sie sich vor, Sie arbeiten an einem Projekt mit anderen Personen und diese haben einige Updates vorgenommen. Sie müssen diese Updates auf Ihren lokalen Rechner holen. Der Befehl git fetch ist genau dafür da. Er lädt die neuesten Änderungen aus einem Remoterepository herunter, ohne sie jedoch in Ihren aktuellen Branch zu mergen.

Zunächst simulieren wir das Vorhandensein eines Remoterepositorys. Wir erstellen ein "bare" (nacktes) Repository und fügen es dann als Remote zu unserem bestehenden my-time-machine-Repository hinzu.

cd ~/project
mkdir remote-repo.git
cd remote-repo.git
git init --bare

Dies erstellt ein "bare" Git-Repository, das normalerweise als zentrales Repository verwendet wird, von dem Entwickler pushen und pullen.

Jetzt kehren wir zu unserem my-time-machine-Repository zurück und fügen dieses "bare" Repository als Remote hinzu.

cd ~/project/my-time-machine
git remote add origin ~/project/remote-repo.git

Wir haben unseren Remote origin benannt, was eine gängige Konvention ist. Jetzt überprüfen wir, ob der Remote korrekt hinzugefügt wurde.

git remote -v

Sie sollten eine Ausgabe ähnlich der folgenden sehen, die die Fetch- und Push-URLs für den origin-Remote anzeigt:

origin	/home/labex/project/remote-repo.git (fetch)
origin	/home/labex/project/remote-repo.git (push)

Jetzt simulieren wir eine Änderung im Remoterepository. Da es sich um ein "bare" Repository handelt, können wir nicht direkt Commits darin erstellen. Stattdessen simulieren wir eine Änderung, indem wir eine neue Datei im Verzeichnis des "bare" Repositorys erstellen.

cd ~/project/remote-repo.git
echo "This is a remote change" > remote_file.txt

Jetzt kehren Sie zu Ihrem my-time-machine-Repository zurück.

cd ~/project/my-time-machine

An diesem Punkt weiß Ihr lokales Repository nichts von der remote_file.txt, die in das simulierte Remote hinzugefügt wurde. Hier kommt git fetch ins Spiel.

Führen Sie den Befehl git fetch aus:

git fetch origin

Sie sehen möglicherweise nicht viel Ausgabe oder etwas, das darauf hinweist, dass neue Objekte empfangen wurden.

Was git fetch origin getan hat, war, sich mit dem origin-Remote zu verbinden und alle neuen Commits und Objekte herunterzuladen, die nicht in Ihrem lokalen Repository vorhanden sind. Es hat diese Änderungen jedoch nicht in Ihren aktuellen Branch (master) gemergt. Die Änderungen sind jetzt in Ihrem lokalen Repository verfügbar, werden aber in einem speziellen Branch gespeichert, der den Remote verfolgt, normalerweise origin/master genannt.

Dies ist ein wesentlicher Unterschied zwischen git fetch und git pull. git pull ist im Wesentlichen git fetch gefolgt von einem Merge. Indem Sie zuerst git fetch verwenden, können Sie sehen, welche Änderungen auf dem Remote verfügbar sind, bevor Sie entscheiden, sie in Ihre Arbeit zu integrieren. Dies gibt Ihnen mehr Kontrolle und hilft, unerwartete Konflikte zu vermeiden.

Im nächsten Schritt sehen wir, wie man seinen lokalen Branch mit dem abgerufenen Remote-Branch vergleicht, um zu verstehen, welche Änderungen heruntergeladen wurden.

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

Im vorherigen Schritt haben wir git fetch verwendet, um Änderungen aus dem Remoterepository herunterzuladen. Jetzt sehen wir uns an, wie wir die Commits anzeigen können, die auf dem Remote vorhanden sind, aber noch nicht in unserem lokalen Branch. Hier ist der Befehl git log HEAD..@{u} sehr nützlich.

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

cd ~/project/my-time-machine

Jetzt führen Sie den folgenden Befehl aus:

git log HEAD..@{u}

Sie sehen möglicherweise eine Ausgabe ähnlich der folgenden:

commit abcdef1234567890abcdef1234567890abcdef (origin/master)
Author: Simulated User <[email protected]>
Date:   Mon Aug 7 10:05:00 2023 +0000

    Simulated remote commit

Lassen Sie uns diesen Befehl analysieren:

• git log: Dies ist der Befehl, um die Commit-Historie anzuzeigen.
• HEAD: Dies bezieht sich auf den Commit, auf den Ihr aktueller Branch zeigt.
• @{u}: Dies ist eine Abkürzung für den Upstream-Branch. In unserem Fall, da wir von origin geholt haben und unser lokaler master-Branch origin/master verfolgt, bezieht sich @{u} auf origin/master.
• HEAD..@{u}: Dies ist eine Bereichsnotation in Git. Sie bedeutet "zeige mir die Commits, die von @{u} erreichbar, aber nicht von HEAD erreichbar sind". Einfacher ausgedrückt, zeigt es Ihnen die Commits, die auf dem Remote-Tracking-Branch (origin/master) vorhanden sind, aber nicht auf Ihrem aktuellen lokalen Branch (master).

Dieser Befehl ist unglaublich hilfreich, um zu sehen, welche Änderungen Sie erhalten würden, wenn Sie Ihren lokalen Branch mit dem Remote-Tracking-Branch mergen oder rebasen würden. Er ermöglicht es Ihnen, die ankommenden Änderungen zu überprüfen, bevor Sie sie integrieren, was ein entscheidender Teil eines sicheren und kontrollierten Arbeitsablaufs ist.

Sie fragen sich vielleicht: "Wie hat Git von dem simulierten Remote-Commit erfahren?" Als wir im vorherigen Schritt git fetch origin ausgeführt haben, hat Git die Informationen über die Commits im origin-Repository heruntergeladen, einschließlich des Commits, der remote_file.txt eingeführt hat. Diese Informationen werden im origin/master-Tracking-Branch in Ihrem lokalen Repository gespeichert. Der Befehl git log HEAD..@{u} vergleicht dann Ihren lokalen master-Branch (HEAD) mit diesem origin/master-Tracking-Branch (@{u}), um Ihnen den Unterschied anzuzeigen.

Drücken Sie q, um die Log-Ansicht zu verlassen, wenn sie im Vollbildmodus ist.

Das Verständnis des Unterschieds zwischen Ihrem lokalen Branch und dem Remote-Tracking-Branch ist grundlegend für die effektive Arbeit mit Remoterepositorys. Dieser Befehl bietet eine klare Möglichkeit, diese Unterschiede zu visualisieren.

Testen von synchronisierten Remotes

In den vorherigen Schritten haben wir Änderungen aus einem simulierten Remoterepository geholt und gelernt, wie man die Commits anzeigt, die auf dem Remote vorhanden sind, aber nicht in unserem lokalen Branch, indem wir git log HEAD..@{u} verwendet haben. Jetzt sehen wir uns an, was passiert, wenn unser lokaler Branch mit dem Remote-Tracking-Branch auf dem neuesten Stand ist.

Zunächst simulieren wir das Mergen der Remote-Änderungen in unseren lokalen Branch. Während git fetch nur Änderungen herunterlädt, lädt git pull Änderungen herunter und führt dann ein Merge durch. Zu Testzwecken simulieren wir den Zustand nach einem Pull, indem wir unseren lokalen Branch manuell aktualisieren, damit er mit dem Remote-Tracking-Branch übereinstimmt.

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

cd ~/project/my-time-machine

Jetzt simulieren wir das Merge, indem wir unseren lokalen master-Branch auf denselben Commit wie origin/master zurücksetzen. Hinweis: In einem realen Szenario würden Sie normalerweise git merge origin/master oder git pull origin master verwenden, um Änderungen zu integrieren. Wir verwenden hier git reset --hard nur zu Demonstrationszwecken, um unseren lokalen Branch schnell für den Test mit dem Remote-Tracking-Branch in Übereinstimmung zu bringen.

git reset --hard origin/master

Sie sollten eine Ausgabe sehen, die darauf hinweist, dass Ihr Branch aktualisiert wurde und der Arbeitsbereich sauber ist.

HEAD is now at abcdef1 Simulated remote commit

Jetzt, da unser lokaler master-Branch mit origin/master synchronisiert ist, führen wir erneut den Befehl git log HEAD..@{u} aus.

git log HEAD..@{u}

Diesmal sollten Sie keine Ausgabe sehen.

Warum keine Ausgabe? Weil HEAD (unser lokaler master-Branch) und @{u} (der origin/master-Tracking-Branch) jetzt auf denselben Commit zeigen. Der Bereich HEAD..@{u} ist leer, weil es keine Commits gibt, die von @{u} erreichbar sind, aber nicht auch von HEAD erreichbar.

Dies ist das erwartete Verhalten, wenn Ihr lokaler Branch vollständig mit seinem Upstream-Remote-Tracking-Branch synchronisiert ist. Der Befehl git log HEAD..@{u} ist eine schnelle Möglichkeit, zu überprüfen, ob es irgendwelche ankommenden Änderungen vom Remote gibt, die Sie noch nicht integriert haben. Wenn der Befehl keine Ausgabe zeigt, bedeutet dies, dass Ihr lokaler Branch mit dem Remote-Tracking-Branch auf dem neuesten Stand ist.

Das Verständnis, wie man nach ankommenden Änderungen sucht und wie man die Ausgabe von git log HEAD..@{u} interpretiert, ist essentiell für die Zusammenarbeit mit anderen und die Synchronisierung Ihres lokalen Repositorys mit dem Remote.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Remote neue Commits hat. Wir haben zunächst das Ziel von git fetch verstanden, das Änderungen aus einem Remoterepository herunterlädt, ohne sie zu mergen. Wir haben ein Remote-Repository simuliert, indem wir ein leeres Git-Repository erstellt und es als Remote namens origin zu unserem lokalen my-time-machine-Repository hinzugefügt haben. Wir haben die Remote-Konfiguration mit git remote -v überprüft.

Als Nächstes haben wir eine Änderung im Remoterepository simuliert, indem wir direkt im Verzeichnis des leeren Repositorys eine Datei erstellt haben. Anschließend haben wir den Befehl git fetch origin verwendet, um diese Änderungen in unser lokales Repository zu holen und uns so auf die Prüfung auf neue Commits vorzubereiten.