Die Staging Area

Teil des Abschnitts Versionsverwaltung der Terminal-Journey von Coddy — Lektion 9 von 58.

Git committet nicht jede Änderung automatisch. Stattdessen wählen Sie explizit aus, welche Änderungen in den nächsten Snapshot einfließen. Dieser zweistufige Workflow ist um den Staging-Bereich herum aufgebaut.

Stellen Sie es sich wie eine Zwischenablage für den nächsten Commit vor. Eine Datei durchläuft drei Zustände:

Arbeitsverzeichnis: wo Sie Dateien normalerweise bearbeiten.
Staging-Bereich: Änderungen, die Sie für den nächsten Commit markiert haben.
Repository: die dauerhafte Historie, nachdem Sie committen.

Der Sinn des Staging ist Kontrolle. Sie können zehn Dateien bearbeiten, aber nur die zwei stagen, die sich auf eine Fehlerbehebung beziehen, diese committen und dann den Rest separat stagen und committen. Jeder Commit konzentriert sich so auf eine logische Änderung.

Sie verschieben Dateien mit git add in den Staging-Bereich und vom Staging-Bereich mit git commit in das Repository.

Aufgabe

Anfänger

Der Ordner enthält eine untracked Datei app.txt. Initialisieren Sie das Repository und führen Sie dann git status --short aus, um zu bestätigen, dass die Datei als untracked angezeigt wird.

Spickzettel

Git verwendet einen zweistufigen Workflow, um Commits zu erstellen:

Arbeitsverzeichnis – wo Sie Dateien bearbeiten
Staging-Bereich – Änderungen, die für den nächsten Commit markiert sind
Repository – permanente Historie nach dem Committen

Bereiten Sie Änderungen mit git add vor und speichern Sie diese anschließend mit git commit in der Historie. Dies ermöglicht es Ihnen, zusammengehörige Änderungen in fokussierten Commits zu gruppieren, selbst wenn mehrere Dateien bearbeitet wurden.

Probier es selbst

Terminal