Wie man prüft, ob eine Datei in Git in die Staging-Area aufgenommen wurde

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob eine Datei in Git in die Staging-Area (Zwischenspeicher) aufgenommen wurde. Wir werden den Befehl git status untersuchen, um den Zustand Ihres Repositorys zu sehen und die in die Staging-Area aufgenommenen Dateien zu identifizieren. Anschließend verwenden Sie git diff --cached, um die spezifischen Änderungen zu überprüfen, die derzeit in der Staging-Area sind. Dies gibt Ihnen einen klaren Überblick darüber, was in Ihrem nächsten Commit enthalten sein wird. Abschließend testen Sie mit nicht in die Staging-Area aufgenommenen Dateien, um Ihr Verständnis des Staging-Prozesses zu festigen.

Skills Graph

Überprüfen des Git-Status für in die Staging-Area aufgenommene Dateien

In diesem Schritt werden wir den Status unseres Git-Repositorys überprüfen, nachdem wir eine Datei in die Staging-Area (Zwischenspeicher) aufgenommen haben. Dies hilft uns zu verstehen, wie Git Änderungen verfolgt, bevor sie committet werden.

Zunächst stellen Sie sicher, dass Sie sich im Verzeichnis my-time-machine befinden. Sie können den cd-Befehl verwenden, um dorthin zu navigieren:

cd ~/project/my-time-machine

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

echo "Plan 1: Build a bigger time machine" > future_plans.txt

Dieser Befehl erstellt die Datei und schreibt den Text "Plan 1: Build a bigger time machine" hinein.

Als Nächstes fügen wir diese neue Datei mit dem git add-Befehl in die Staging-Area ein:

git add future_plans.txt

Denken Sie daran, dass git add die Änderungen in die Staging-Area aufnimmt und sie für den nächsten Commit vorbereitet. Es erstellt noch nicht den Commit selbst.

Jetzt überprüfen wir den Status unseres Repositorys mit git status:

git status

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt ## Diese Datei ist bereits committet, aber der Git-Status zeigt sie nach einem Commit anders an. Machen Sie sich darüber momentan keine Sorgen.

Beachten Sie den Abschnitt "Changes to be committed:" (Änderungen, die committet werden sollen). Dies zeigt an, dass future_plans.txt jetzt in der Staging-Area ist und für den nächsten Commit bereit ist. Git erkennt sie als "neue Datei".

Das Verständnis der Staging-Area ist in Git von entscheidender Bedeutung. Sie ermöglicht es Ihnen, verwandte Änderungen zusammenzufassen, bevor Sie einen Commit erstellen. Das bedeutet, dass Sie an mehreren Dingen arbeiten können, aber nur bestimmte Änderungen committen, wenn sie fertig sind.

Verwenden von git diff --cached zur Überprüfung

In diesem Schritt lernen wir, wie man die momentan in der Staging-Area (Zwischenspeicher) befindlichen Änderungen einsehen kann. Hier kommt der git diff-Befehl, speziell mit der Option --cached, sehr nützlich zum Einsatz.

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

Wir haben zuvor future_plans.txt in die Staging-Area aufgenommen. Jetzt verwenden wir git diff --cached, um genau zu sehen, welche Änderungen in die Staging-Area aufgenommen wurden:

git diff --cached

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

diff --git a/future_plans.txt b/future_plans.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/future_plans.txt
@@ -0,0 +1 @@
+Plan 1: Build a bigger time machine

Lassen Sie uns diese Ausgabe analysieren:

• diff --git a/future_plans.txt b/future_plans.txt: Diese Zeile zeigt an, dass Git den Unterschied zwischen zwei Versionen der Datei future_plans.txt anzeigt.
• new file mode 100644: Dies zeigt, dass future_plans.txt eine neue Datei ist.
• index 0000000..a1b2c3d: Dies sind interne Git-Identifikatoren für den Inhalt der Datei.
• --- /dev/null und +++ b/future_plans.txt: Diese Zeilen zeigen an, dass die Datei von nichts (/dev/null) zur neuen Version von future_plans.txt verglichen wird.
• @@ -0,0 +1 @@: Dies ist ein "Hunk-Header" (Änderungsblock-Header), der die geänderten Zeilen angibt. -0,0 bedeutet null Zeilen aus der ursprünglichen (nicht existierenden) Datei, und +1 bedeutet eine Zeile in der neuen Datei.
• +Plan 1: Build a bigger time machine: Das +-Zeichen am Anfang der Zeile zeigt an, dass diese Zeile hinzugefügt wurde.

Der git diff --cached-Befehl zeigt Ihnen den Unterschied zwischen der Staging-Area und dem letzten Commit. Da wir in diesem Repository bisher noch keine Commits gemacht haben (außer dem initialen Commit im vorherigen Lab), zeigt er den Unterschied zwischen der Staging-Area und einem leeren Zustand.

Dieser Befehl ist unglaublich nützlich, um Ihre in die Staging-Area aufgenommenen Änderungen zu überprüfen, bevor Sie sie committen. Er hilft Ihnen sicherzustellen, dass Sie nur die Änderungen committen, die Sie beabsichtigen.

Drücken Sie q, um die Diff-Ansicht zu verlassen und zur Befehlszeile zurückzukehren.

Testen von nicht in die Staging-Area aufgenommenen Dateien

In diesem Schritt werden wir untersuchen, wie Git Änderungen an einer verfolgten Datei behandelt, die noch nicht in die Staging-Area (Zwischenspeicher) aufgenommen wurden. Diese werden "unstaged" (nicht in die Staging-Area aufgenommene) Änderungen genannt.

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

Wir haben zuvor future_plans.txt erstellt und in die Staging-Area aufgenommen. Jetzt fügen wir dieser Datei eine weitere Zeile hinzu, ohne die Änderung in die Staging-Area aufzunehmen:

echo "Plan 2: Invent a self-folding laundry machine" >> future_plans.txt

Der >>-Operator hängt den Text an die bestehende Datei an, anstatt sie zu überschreiben.

Jetzt überprüfen wir erneut den Status unseres Repositorys:

git status

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   future_plans.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt

Beachten Sie den neuen Abschnitt: "Changes not staged for commit:" (Änderungen, die nicht für den Commit in die Staging-Area aufgenommen wurden). Dies zeigt uns, dass Git Änderungen in future_plans.txt erkennt, die sich von der Version in der Staging-Area unterscheiden. Die Datei wird als "modified" (geändert) aufgeführt.

Dies ist ein Schlüsselkonzept in Git: Das Arbeitsverzeichnis (wo Sie Änderungen vornehmen) ist vom Staging-Area getrennt. Sie können Änderungen in Ihrem Arbeitsverzeichnis haben, die noch nicht in die Staging-Area aufgenommen wurden.

Um den Unterschied zwischen dem Arbeitsverzeichnis und der Staging-Area zu sehen, können Sie git diff ohne zusätzliche Optionen verwenden:

git diff

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

diff --git a/future_plans.txt b/future_plans.txt
index a1b2c3d..e4f5g6h 100644
--- a/future_plans.txt
+++ b/future_plans.txt
@@ -1 +1,2 @@
 Plan 1: Build a bigger time machine
+Plan 2: Invent a self-folding laundry machine

Diese Ausgabe zeigt den Unterschied zwischen der Version von future_plans.txt in der Staging-Area (die nur "Plan 1" enthält) und der Version in Ihrem Arbeitsverzeichnis (die jetzt sowohl "Plan 1" als auch "Plan 2" enthält). Das +-Zeichen zeigt wiederum die hinzugefügte Zeile an.

Das Verständnis des Unterschieds zwischen in die Staging-Area aufgenommenen und nicht aufgenommenen Änderungen sowie die Möglichkeit, sie mit git status und git diff anzuzeigen, ist grundlegend für die effektive Nutzung von Git.

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

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob eine Datei in Git in die Staging-Area (Zwischenspeicher) aufgenommen wurde. Wir haben begonnen, indem wir eine neue Datei erstellt und sie mit git add in die Staging-Area aufgenommen haben. Anschließend haben wir git status verwendet, um festzustellen, dass die Datei unter "Changes to be committed" (Änderungen, die für den Commit vorgemerkt sind) aufgeführt war, was bestätigt, dass sie in die Staging-Area aufgenommen wurde.

Wir haben auch untersucht, wie man git diff --cached verwendet, um die spezifischen Änderungen anzuzeigen, die derzeit in der Staging-Area sind. Dies gibt einen detaillierten Einblick in das, was in den nächsten Commit aufgenommen werden wird. Schließlich haben wir das Verhalten von git status mit nicht in die Staging-Area aufgenommenen Dateien getestet, um zwischen in die Staging-Area aufgenommenen und nicht aufgenommenen Änderungen zu unterscheiden.