Staging, Committen und Verlauf

In Git ist der Staging-Bereich (auch Index genannt) ein wichtiger Zwischenschritt zwischen Ihrem Arbeitsverzeichnis und Ihrem Repository.

Stellen Sie ihn sich als Warteraum vor, in dem Sie Änderungen vorbereiten, bevor Sie sie dauerhaft speichern.

So können Sie zusammengehörige Änderungen zu einem einzigen aussagekräftigen Commit zusammenfassen.

Um Änderungen aus Ihrem Arbeitsverzeichnis in den Staging-Bereich zu verschieben, verwenden Sie den Befehl git add.

Sie geben die Datei(en) an, die Sie für den Commit vormerken möchten. Damit teilen Sie Git mit: "Hey, ich möchte diese Änderungen in meinen nächsten Commit aufnehmen!"

Sie müssen Dateien nicht einzeln hinzufügen. Git bietet praktische Möglichkeiten, mehrere Dateien oder sogar alle Änderungen auf einmal für das Staging vorzumerken.

• git add . nimmt alle neuen und geänderten Dateien im aktuellen Verzeichnis und seinen Unterverzeichnissen in das Staging auf.
• git add -u nimmt nur geänderte und gelöschte Dateien auf, keine neuen.

Ein Commit ist wie eine Momentaufnahme Ihres Projekts zu einem bestimmten Zeitpunkt. Er zeichnet die vorgemerkten Änderungen dauerhaft in Ihrem Git-Repository auf.

Jeder Commit besitzt eine eindeutige ID, einen Autor, einen Zeitstempel und eine Commit-Nachricht, die erklärt, welche Änderungen vorgenommen wurden.

Sobald sich Ihre Änderungen im Staging-Bereich befinden, können Sie sie mit git commit committen. Sie sollten immer eine klare und prägnante Nachricht hinzufügen, die die Änderungen beschreibt.

Mit dem Flag -m können Sie die Commit-Nachricht direkt angeben.

Der Befehl git status ist Ihr bester Helfer! Er zeigt Ihnen:

• Welche Dateien nicht versioniert sind, also neu und noch nicht zu Git hinzugefügt wurden.
• Bei welchen Dateien Änderungen für einen Commit bereitstehen, also vorgemerkt wurden.
• Bei welchen Dateien Änderungen noch nicht für das Staging vorgemerkt wurden.

Bevor Sie Änderungen für das Staging vormerken oder committen, sollten Sie sie überprüfen. Mit dem Befehl git diff sehen Sie genau, was sich in Ihren Dateien geändert hat.

Standardmäßig zeigt git diff Änderungen in Ihrem Arbeitsverzeichnis an, die noch *nicht* für das Staging vorgemerkt wurden.

Was ist, wenn Sie die Änderungen sehen möchten, die Sie bereits in den Staging-Bereich verschoben haben, bevor Sie sie committen?

Mit git diff --staged (oder git diff --cached) können Sie die vorgemerkten Änderungen mit dem letzten Commit vergleichen.

Um eine chronologische Liste aller Commits in Ihrem Repository anzuzeigen, verwenden Sie den Befehl git log. Er zeigt, wer wann Änderungen vorgenommen hat und welche Commit-Nachrichten verwendet wurden.

Das ist entscheidend, um die Entwicklung Ihres Projekts zu verstehen!

Die standardmäßige Ausgabe von git log kann sehr detailliert sein. Für einen schnellen Überblick können Sie Optionen verwenden, um sie zu vereinfachen:

• git log --oneline: Zeigt jeden Commit in einer einzelnen Zeile an.
• git log --graph: Stellt die Commit-Historie als ASCII-Baum dar.

Sie haben gerade index.html geändert und eine neue Datei namens style.css erstellt. Sie möchten beide in Ihren nächsten Commit aufnehmen.

Welche Befehlsfolge nimmt diese Änderungen korrekt in das Staging auf und committet sie?

Sehr gut! In dieser Lektion haben Sie die grundlegenden Schritte des lokalen Git-Workflows kennengelernt:

• Im Staging-Bereich (Index) bereiten Sie Änderungen vor.
• Verwenden Sie git add, um Änderungen in den Staging-Bereich zu verschieben.
• Ein Commit ist eine dauerhafte Momentaufnahme Ihrer bereitgestellten Änderungen.
• Verwenden Sie git commit -m "message", um einen Commit zu speichern.
• git status zeigt den Zustand Ihres Arbeitsverzeichnisses an.
• git diff hilft Ihnen dabei, Änderungen zu überprüfen.
• Mit git log können Sie die Historie Ihres Projekts erkunden.

Diese Befehle sind grundlegend, um den Fortschritt Ihres Projekts nachzuverfolgen!