So prüfen Sie, ob ein Git-Repository gestagte Änderungen aufweist

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob in einem Git-Repository (Git-Repository) Änderungen im Staging-Bereich (Staging Area) vorliegen. Sie verwenden den Befehl git status, um die im Staging-Bereich befindlichen Dateien anzuzeigen und die Ausgabe zu verstehen, die den aktuellen Zustand Ihres Repositorys angibt, einschließlich geänderter, im Staging-Bereich befindlicher und nicht verfolgter Dateien.

Darüber hinaus werden Sie untersuchen, wie Sie git diff --cached verwenden können, um die spezifischen Änderungen zu untersuchen, die derzeit im Staging-Bereich sind. Dies ermöglicht es Ihnen, die Unterschiede zwischen den im Staging-Bereich befindlichen und den nicht im Staging-Bereich befindlichen Änderungen in Ihrem Repository zu überprüfen.

Skills Graph

Verwenden von git status zum Anzeigen von Dateien im Staging-Bereich

In diesem Schritt verwenden wir erneut den Befehl git status, um zu sehen, wie Git Änderungen nach dem Hinzufügen einer Datei verfolgt.

Zunächst stellen Sie sicher, dass Sie sich im Verzeichnis my-time-machine befinden. Wenn nicht, verwenden Sie den Befehl cd:

cd ~/project/my-time-machine

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

echo "Ideas for the future" > notes.txt

Dieser Befehl erstellt die Datei notes.txt mit dem angegebenen Text.

Als Nächstes teilen wir Git mit, dass wir diese neue Datei verfolgen möchten. Hierzu verwenden wir den Befehl git add:

git add notes.txt

Dieser Befehl fügt notes.txt in den Staging-Bereich (Staging Area) ein. Der Staging-Bereich ist wie ein Wartezimmer für Änderungen, bevor sie committet werden.

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:   notes.txt

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

Beachten Sie, dass die Ausgabe jetzt notes.txt unter "Changes to be committed" anzeigt. Dies bedeutet, dass die Datei sich im Staging-Bereich befindet und für den nächsten Commit bereit ist.

Möglicherweise sehen Sie auch message.txt unter "Untracked files" aufgeführt. Dies liegt daran, dass wir die Änderungen an message.txt aus den vorherigen Schritten noch nicht committet haben. Git zeigt uns, dass es noch Änderungen im Arbeitsverzeichnis gibt, die für den nächsten Commit nicht verfolgt werden.

Das Verständnis der Ausgabe von git status ist von entscheidender Bedeutung. Es gibt Ihnen den aktuellen Zustand Ihres Repositorys an, zeigt an, welche Dateien geändert wurden, welche für den Commit im Staging-Bereich sind und welche nicht verfolgt werden. Dies hilft Ihnen, Ihre Arbeit zu verfolgen und zu entscheiden, was in Ihrem nächsten Savepoint (Commit) enthalten sein soll.

Überprüfen der Änderungen mit git diff --cached

In diesem Schritt lernen wir, wie wir die genauen Änderungen, die derzeit im Staging-Bereich (Staging Area) sind, mit dem Befehl git diff --cached anzeigen können.

Denken Sie an den vorherigen Schritt, in dem wir notes.txt in den Staging-Bereich aufgenommen haben. Jetzt schauen wir uns an, welche Änderungen Git bereit ist, zu committen.

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

cd ~/project/my-time-machine

Jetzt führen Sie den folgenden Befehl aus:

git diff --cached

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

diff --git a/notes.txt b/notes.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/notes.txt
@@ -0,0 +1 @@
+Ideas for the future

Diese Ausgabe zeigt Ihnen den Unterschied zwischen dem Staging-Bereich und dem letzten Commit. Da dies das erste Mal ist, dass wir notes.txt in den Staging-Bereich aufnehmen, zeigt Git es als neue Datei an.

Lassen Sie uns die Ausgabe analysieren:

• diff --git a/notes.txt b/notes.txt: Diese Zeile gibt an, dass wir zwei Versionen der Datei notes.txt vergleichen.
• new file mode 100644: Dies zeigt, dass notes.txt eine neue Datei ist.
• index 0000000..a1b2c3d: Dies sind interne Git-Identifikatoren für den Inhalt der Datei.
• --- /dev/null: Dies repräsentiert den "leeren" Zustand vor dem Hinzufügen der Datei.
• +++ b/notes.txt: Dies repräsentiert den aktuellen Zustand der Datei im Staging-Bereich.
• @@ -0,0 +1 @@: Dies ist ein Header, der die geänderten Zeilen angibt. -0,0 bedeutet, dass in der ursprünglichen (leeren) Version keine Zeilen vorhanden waren, und +1 bedeutet, dass in der neuen Version eine Zeile hinzugefügt wurde.
• +Ideas for the future: Das Pluszeichen + gibt an, dass diese Zeile hinzugefügt wurde.

Der Befehl git diff --cached ist unglaublich nützlich, um Ihre im Staging-Bereich befindlichen Änderungen zu überprüfen, bevor Sie sie committen. Er ermöglicht es Ihnen, genau zu überprüfen, was Sie in der Projektgeschichte speichern möchten. Dies hilft, versehentliches Committen von unerwünschten Änderungen zu vermeiden.

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

Überprüfen von gestagten und nicht-gestagten Änderungen

In diesem Schritt werden wir den Unterschied zwischen gestagten (staged) und nicht-gestagten Änderungen weiter untersuchen, indem wir eine Datei ändern, die bereits von Git verfolgt wird.

Zunächst stellen Sie sicher, dass Sie sich im Verzeichnis ~/project/my-time-machine befinden:

cd ~/project/my-time-machine

Jetzt fügen wir unserer notes.txt-Datei noch eine Zeile hinzu. Wir können den echo-Befehl mit >> verwenden, um Text an eine vorhandene Datei anzuhängen:

echo "Another idea" >> notes.txt

Dieser Befehl fügt die Zeile "Another idea" am Ende von notes.txt hinzu.

Lassen Sie uns erneut den Status unseres Repositorys überprüfen:

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:   notes.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:   notes.txt

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

Beachten Sie, dass notes.txt jetzt in zwei Abschnitten erscheint:

1. Changes to be committed: Dies bezieht sich auf die Version von notes.txt, die wir im vorherigen Schritt in den Staging-Bereich aufgenommen haben (die nur "Ideas for the future" enthielt).
2. Changes not staged for commit: Dies bezieht sich auf die Änderungen, die wir gerade an notes.txt vorgenommen haben (das Hinzufügen von "Another idea"). Diese Änderungen befinden sich in unserem Arbeitsverzeichnis, wurden aber noch nicht in den Staging-Bereich aufgenommen.

Dies ist ein Schlüsselkonzept in Git: Der Staging-Bereich enthält eine Momentaufnahme der Änderungen, die für den nächsten Commit bereit sind, während das Arbeitsverzeichnis den aktuellen Zustand Ihrer Dateien enthält, einschließlich Änderungen, die noch nicht gestaggt wurden.

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

git diff

Dies zeigt Ihnen die Änderungen, die nicht gestaggt sind. Sie sollten eine Ausgabe sehen, die die Hinzufügung der Zeile "Another idea" anzeigt.

Um den Unterschied zwischen dem Staging-Bereich und dem letzten Commit zu sehen (den wir im vorherigen Schritt gesehen haben), verwenden Sie git diff --cached.

Das Verständnis des Unterschieds zwischen gestagten und nicht-gestagten Änderungen und wie man sie mit git status und git diff anzeigt, ist grundlegend für die effektive Nutzung von Git. Es gibt Ihnen präzise Kontrolle darüber, was in jeden Commit aufgenommen wird.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Repository gestagte Änderungen (staged changes) aufweist. Wir haben begonnen, indem wir den Befehl git status verwendet haben, um den aktuellen Zustand des Repositorys anzuzeigen, einschließlich der Dateien, die in den Staging-Bereich (Staging Area) aufgenommen wurden. Wir haben gesehen, wie git status klar zeigt, welche Dateien "Changes to be committed" sind.

Als Nächstes haben wir uns den Befehl git diff --cached angeschaut, um speziell die Unterschiede zwischen den gestagten Änderungen und dem letzten Commit anzuzeigen. Dies hat es uns ermöglicht, die genauen Inhaltsänderungen zu sehen, die bereit sind, committet zu werden. Schließlich haben wir die Unterscheidung zwischen gestagten und nicht-gestagten Änderungen vertieft und verstanden, dass git status einen Überblick bietet, während git diff --cached den detaillierten Inhalt der gestagten Änderungen zeigt.