So prüfen Sie, ob ein Git-Repository mit dem Remote-Repository auf dem neuesten Stand ist

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob Ihr lokales Git-Repository mit seinem Remote-Repository (Entfernten Repository) auf dem neuesten Stand ist. Wir werden die wesentlichen Schritte dazu abdecken, beginnend mit dem Abrufen der neuesten Änderungen aus dem Remote-Repository, ohne Ihre lokale Arbeit zu verändern.

Nach der Fetch-Operation (Abrufoperation) lernen Sie, wie Sie Ihren lokalen Branch (Zweig) mit dem Remote-Branch vergleichen, um eventuelle Unterschiede zu identifizieren. Abschließend werden wir untersuchen, wie Sie den Befehl git log verwenden können, um visuell zu überprüfen, dass Ihre lokalen Commits (Einträge) mit dem Remote-Repository synchronisiert sind und Sie somit die aktuellste Version des Projekts haben.

Skills Graph

Abrufen von Remote-Änderungen mit git fetch

In diesem Schritt lernen wir, wie man Änderungen aus einem Remote-Git-Repository abruft. Stellen Sie sich vor, Sie arbeiten an einem Projekt mit anderen Personen und diese haben einige Updates vorgenommen. Mit dem Befehl git fetch können Sie diese Updates abrufen, ohne Ihre eigene Arbeit zu verändern.

Zunächst simulieren wir das Vorhandensein eines Remote-Repositories. Dazu fügen wir einer bestehenden lokalen Repository eine Remote-URL hinzu. In der Realität wäre dies die URL eines Repositories, das auf einer Plattform wie GitHub oder GitLab gehostet wird.

Navigieren Sie in das Projektverzeichnis, falls Sie nicht bereits dort sind:

cd ~/project/my-time-machine

Nun fügen wir eine Platzhalter-Remote-URL hinzu. Wir nennen diesen Remote origin, was eine gängige Konvention ist.

git remote add origin https://github.com/example/my-time-machine.git

Dieser Befehl erzeugt keine Ausgabe, aber er hat Ihre lokale Repository so konfiguriert, dass sie von einem Remote-Repository namens origin weiß.

Nun verwenden wir git fetch, um Informationen über die Änderungen im Remote-Repository abzurufen. Da dies eine Platzhalter-URL ist, lädt git fetch tatsächlich keinen Code herunter, aber es simuliert den Prozess und zeigt Ihnen, was passieren würde.

git fetch origin

Möglicherweise sehen Sie eine Ausgabe ähnlich dieser (die genaue Ausgabe kann je nach Git-Version und Konfiguration variieren):

fatal: repository 'https://github.com/example/my-time-machine.git/' not found

Machen Sie sich keine Sorgen über den Fehler "repository not found" (Repository nicht gefunden). Dies ist zu erwarten, da wir eine Platzhalter-URL verwendet haben. Der Wichtige Teil ist, dass Sie den git fetch-Befehl ausgeführt haben.

In einer realen Situation würde git fetch origin eine Verbindung zum Remote-Repository herstellen, alle neuen Commits (Einträge) und Branches (Zweige), die in Ihrer lokalen Repository nicht existieren, herunterladen und sie in einem speziellen Bereich speichern. Es führt diese Änderungen nicht in Ihren aktuellen Arbeitsbranch ein. Dies ermöglicht es Ihnen, zu sehen, welche Änderungen von anderen vorgenommen wurden, bevor Sie entscheiden, sie in Ihre eigene Arbeit zu integrieren.

Denken Sie sich git fetch wie einen Besuch in der Post, um Post zu holen. Sie holen die Post (die Änderungen) ab, aber Sie öffnen sie nicht und legen sie auf Ihren Schreibtisch (führen sie in Ihre Arbeit ein), bis Sie bereit sind.

Vergleich von lokalem und Remote-Repository mit git status

In diesem Schritt verwenden wir den Befehl git status, um zu sehen, wie unser lokales Repository im Vergleich zum Remote-Repository aussieht, nachdem wir die Änderungen abgerufen haben.

Navigieren Sie in das Projektverzeichnis, falls Sie nicht bereits dort sind:

cd ~/project/my-time-machine

Führen Sie nun den Befehl git status aus:

git status

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

nothing to commit, working tree clean

Lassen Sie uns diese Ausgabe analysieren:

• "On branch master": Dies gibt an, dass Sie derzeit auf dem master-Branch (Zweig) sind.
• "Your branch is up to date with 'origin/master'": Dies ist der wichtigste Teil. Es zeigt an, dass Ihr lokaler master-Branch die gleichen Commits (Einträge) wie der master-Branch im origin-Remote-Repository hat.

Obwohl unser git fetch-Befehl im vorherigen Schritt aufgrund der Platzhalter-Remote-URL zu einem Fehler führte, hat Git dennoch seine internen Nachverfolgungsinformationen aktualisiert. In einer realen Situation, in der git fetch erfolgreich neue Commits abruft, würde die git status-Ausgabe Ihnen mitteilen, dass Ihr lokaler Branch hinter dem Remote-Branch zurückliegt und vorschlagen, dass Sie git pull ausführen, um die Änderungen zu integrieren.

Der Befehl git status ist Ihr Fenster in den Zustand Ihres Repositories. Es sagt Ihnen, auf welchem Branch Sie sich befinden, ob Ihr lokaler Branch mit seinem Remote-Gegenstück synchronisiert ist und ob Sie uncommittete Änderungen in Ihrem Arbeitsverzeichnis oder im Staging-Bereich (Zwischenspeicher) haben. Regelmäßiges Prüfen von git status ist eine gute Gewohnheit, um über den Zustand Ihres Projekts informiert zu bleiben.

Verwenden von git log zur Überprüfung synchronisierter Commits

In diesem Schritt verwenden wir den Befehl git log, um die Commit-Historie (Eintragsgeschichte) zu sehen und zu verstehen, wie git fetch das, was wir sehen, beeinflusst.

Navigieren Sie in das Projektverzeichnis, falls Sie nicht bereits dort sind:

cd ~/project/my-time-machine

Führen Sie den Befehl git log aus, um die Commit-Historie anzuzeigen:

git log

Sie sollten den Commit sehen, den Sie im vorherigen Lab (Übungsabschnitt) gemacht haben:

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9 (HEAD -> master, origin/master)
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

Beachten Sie, dass die Ausgabe jetzt (HEAD -> master, origin/master) anzeigt. Dies zeigt an, dass sowohl Ihr lokaler master-Branch (HEAD -> master) als auch der Remote-Tracking-Branch (Nachverfolgungszweig) für origin/master (origin/master) auf denselben Commit zeigen. Dies bestätigt, dass Ihr lokales Repository mit dem Remote-Repository synchronisiert ist (oder zumindest mit den Informationen, die Git über das Remote-Repository nach dem git fetch-Befehl hat).

In einer realen Situation, in der git fetch neue Commits aus dem Remote-Repository geholt hat, würde das Ausführen von git log Ihnen diese neuen Commits anzeigen. Sie würden in der Commit-Historie erscheinen, und der origin/master-Zeiger würde auf den neuesten Commit aus dem Remote-Repository zeigen, während Ihr lokaler master-Branch noch auf Ihrem letzten lokalen Commit verbleiben würde. Dieser sichtbare Unterschied in der Commit-Historie hilft Ihnen, genau zu sehen, welche Änderungen aus dem Remote-Repository verfügbar sind, bevor Sie sie zusammenführen.

Der Befehl git log ist unerlässlich, um die Geschichte Ihres Projekts zu verstehen. Es ermöglicht Ihnen, die Reihenfolge der Commits, wer sie gemacht hat, wann sie gemacht wurden und die Commit-Nachrichten zu sehen. In Kombination mit git fetch hilft es Ihnen, den Unterschied zwischen Ihrer lokalen Commit-Historie und der Commit-Historie im Remote-Repository zu visualisieren.

Drücken Sie q, um die Commit-Historie-Ansicht zu verlassen.

Zusammenfassung

In diesem Lab (Übungsabschnitt) haben wir gelernt, wie man prüft, ob ein lokales Git-Repository mit seinem Remote-Gegenstück auf dem neuesten Stand ist. Wir haben zunächst den Zweck von git fetch verstanden, das Änderungen aus dem Remote-Repository abruft, ohne die lokale Arbeitskopie zu ändern. Wir haben das Hinzufügen eines Remote-Repositories simuliert und dann git fetch ausgeführt, um zu sehen, wie es mit dem Remote-Repository interagiert.

Die folgenden Schritte, die in den bereitgestellten Inhalten nicht vollständig detailliert wurden, würden normalerweise das Verwenden von git status zur Vergleich des lokalen Branches (Zweigs) mit dem abgerufenen Remote-Branch und von git log zur visuellen Prüfung der Commit-Historie (Eintragsgeschichte) und zur Identifizierung von Unterschieden umfassen, um so zu bestätigen, ob das lokale Repository mit dem Remote-Repository synchronisiert ist.