Git verstehen statt nur Befehle nachschlagen: Working Directory, Staging und Commit erklärt

Einleitung

Git fühlt sich schwer an, wenn man es als Sammlung einzelner Befehle lernt. Wer dagegen das System versteht, googelt seltener – und löst Konflikte, Rewrites oder Remote‑Probleme souverän. Dieses Tutorial vermittelt ein kompaktes mentales Modell, das du sofort an einem Test‑Repo nachvollziehen kannst. Es orientiert sich an der offiziellen Dokumentation und erprobten Workflows und ist damit robust genug für den Alltag in Deutschland‑Teams, ob Start‑up oder Enterprise.

Ziel: Du verstehst, was Git intern tut – und wählst danach passende Kommandos aus, statt sie zu raten.

Voraussetzungen und Setup

Ein installiertes Git (aktuelle Stable) und ein Editor reichen. Falls nötig, hol dir Git über dein Paketmanagement oder die offizielle Seite. Setze Name und E‑Mail global, damit deine Commits korrekte Author-/Committer‑Metadaten haben. Kryptografisches Signieren von Commits (z. B. mit GPG/SSH) ist ein separater Schritt und erfordert zusätzliche Konfiguration (siehe z. B. das Kapitel „Deine Arbeit signieren“ in Pro Git).

git config --global user.name "Dein Name"
git config --global user.email "du@example.org"

Wenn du Git noch nie eingerichtet hast oder regelmäßig Credential‑Prompts bekommst, hilft der GitHub‑Leitfaden zu Basis‑Setup und Editor‑Anbindung weiter: Git basics (GitHub Docs).

Für Übungen legst du lokal ein neues Repo an oder klonst eines:

mkdir git-mentales-modell && cd git-mentales-modell
git init

Tipp zum Üben: Das interaktive Playground‑Tool Learn Git Branching visualisiert Branches und Rewrites – ideal, um die folgenden Schritte gefahrlos zu trainieren.

Die drei zentralen Zustände: Working Directory, Staging Area, Commit-Historie

Das Kernprinzip: Git verfolgt Inhalte, nicht Dateien. Ein „Snapshot" einer Datei landet zuerst in der Staging Area (Index) und wird mit einem Commit in die Historie geschrieben. Genau dieses Dreieck bildet dein mentales Modell:

• Working Directory: deine aktuellen, editierbaren Dateien.
• Staging Area (Index): Auswahl deiner nächsten Snapshot‑Version.
• Commit-Historie: unveränderliche Reihe gespeicherter Snapshots mit Metadaten.

Schritt für Schritt:

echo "Hallo" > hallo.txt     # Working Directory ändert sich
git add hallo.txt             # Snapshot von hallo.txt in die Staging Area
git commit -m "Init"          # Stage -> neuer Commit in die Historie

Kontrolliere aktiv, was in der Stage liegt und was committed würde:

git status
git diff            # Unterschiede im Working Directory vs. Stage
git diff --cached   # Unterschiede Stage vs. letztem Commit

Häufiges Missverständnis: „git add“ bedeutet nicht „beginne, diese Datei zu tracken und verfolge jedes Byte automatisch“. Vielmehr speichert add den aktuellen Inhalt als Kandidaten für den nächsten Commit. Diese Sicht wird in der offiziellen Doku und im Git‑Tutorial so erklärt: Inhalte statt Dateien sind ausschlaggebend (Pro Git, Deutsch, gittutorial).

Fehlervermeidung:

• Prüfe vor jedem Commit „git status" und optional „git diff --cached".
• Nutze „git add -p", um hunks selektiv zu stagen.
• Verwechsle nicht: „git commit -a" überspringt die Stage nur für bereits verfolgte Dateien; neue Dateien müssen explizit mit „git add" rein.

Branching und HEAD: das einfache Modell für parallele Arbeit

Ein Branch ist nichts Magisches, sondern ein beweglicher Zeiger auf einen Commit. HEAD wiederum zeigt auf den aktuell ausgecheckten Branch (oder direkt auf einen Commit bei „detached HEAD").

Beispiel‑Workflow:

git switch -c feature/login   # neuen Branch erstellen und wechseln
echo "Form" > login.md
git add login.md && git commit -m "Login-Form skizziert"

git switch main               # zurück auf den Hauptbranch

Worauf du achten solltest:

• Branches sind leichtgewichtig. Erstelle sie früh und oft für Features oder Fixes.
• „git log --oneline --graph --decorate" hilft, den Commit‑Graph zu lesen.
• Ein Wechsel mit „git switch <branch>" stellt Working Directory und Stage exakt auf den Ziel‑Commit‑Zustand.

Zusammenführen: Merge vs. Rebase verständlich wählen

Merge fügt Historien zusammen. Es gibt zwei typische Fälle:

• Fast‑Forward: main zeigt noch auf einen Vorfahren von feature. Git bewegt main einfach nach vorne.
• Echter Merge: Beide Seiten haben neue Commits. Git erzeugt einen Merge‑Commit mit zwei Eltern.

Beispiel:

git switch main
git merge feature/login      # je nach Lage FF oder echter Merge

Rebase „spielt" deine Commits auf eine neue Basis und schreibt damit History um. Ergebnis: lineare, aufgeräumte Historie – nützlich vor dem gemeinsamen Teilen eines Feature‑Branches.

git switch feature/login
git fetch origin
git rebase origin/main       # Commits von feature auf aktuellen main „umhängen"

Wann was?

• Merge bewahrt den echten Entwicklungsverlauf (gut für Team‑Transparenz).
• Rebase erzeugt eine lineare Geschichte (gut für Lesbarkeit) – aber: History‑Rewrite nur für unveröffentlichte Branches oder nach Teamkonvention.

Konflikte lösen (gleich für Merge und Rebase):

git status                    # zeigt Konfliktdateien
# Dateien manuell bearbeiten, Konfliktmarker entfernen

git add <bereinigte-datei>
# bei Merge:
git commit                    # Abschluss-Commit (in neueren Git-Versionen ist alternativ auch "git merge --continue" verfügbar)
# bei Rebase:
git rebase --continue

Die offiziellen Kapitel zu Branching, Merging und Rebasing in Pro Git vertiefen die Details und Strategien (Pro Git, Deutsch).

Arbeiten mit Remotes: Fetch, Pull, Push und Zusammenarbeit

Git trennt bewusst zwischen „Änderungen holen" und „integrieren":

• „git fetch" aktualisiert nur deine Remote‑Tracking‑Branches lokal; es ändert weder Working Directory noch deine lokalen Branches.
• „git pull" ist „fetch + merge" (oder „fetch + rebase" bei entsprechender Konfiguration).
• „git push" veröffentlicht deine lokalen Commits auf dem Remote.

Typische Abfolge im Team:

git fetch origin                 # hol neue Infos
git switch feature/login
# optionaler Rebase gegen aktuellen main
git rebase origin/main
# Arbeit fortsetzen, Commits schreiben

git push -u origin feature/login # Branch erstmalig veröffentlichen

Wenn „git push" verweigert wird (non‑fast‑forward), hast du zwischenzeitlich auf dem Remote neue Commits. Hole sie lokal und integriere sie via Merge oder Rebase:

git fetch origin
git switch main
git merge origin/main   # oder: git rebase origin/main

Pull/Merge‑Requests sind dann der kollaborative Prozess um das Zusammenführen, nicht nur ein Kommando. Der Wert liegt in Review, Checks und Sichtbarkeit.

Undoing Changes: Fehler sicher beheben

Es gibt nicht „den einen" Undo‑Befehl. Wähle je nach Ebene im Dreieck.

Arbeitskopie verwerfen (ungebatchte Änderungen):

Hinweis: ‚git restore‘ ist die modernere, gezieltere Variante zum Zurücksetzen von Arbeitskopien; ‚git checkout‘ funktioniert weiterhin, ist aber historisch und kann in manchen Tutorials noch auftauchen.

git restore <datei>            # Working Directory auf Stage zurücksetzen
# oder gezielt auf letzten Commit:
git checkout HEAD -- <datei>

Stage aufräumen (versehentlich hinzugefügt):

git reset -- <datei>           # entfernt aus Stage, ändert Working Directory nicht

Commit rückgängig machen, ohne History umzuschreiben (sicher, auch wenn schon gepusht):

git revert <commit-sha>

History neu schreiben (nur, wenn noch nicht geteilt oder nach Teamregel):

git reset --hard <ziel-commit> # bewegt Branch-Zeiger und setzt Index/Stage und Working Directory auf den Ziel-Commit
# oder interaktiv Commits neu ordnen/zusammenfassen
git rebase -i <basis>

Eine saubere, fundierte Erklärung der Reset‑Varianten und des Rewrites findest du in Pro Git („Reset entzaubert", „Den Verlauf umschreiben"; Pro Git, Deutsch).

Praktische Lernpfade: so lernst du Git wirklich

• Kleine, überprüfbare Übungen: Initialisiere ein Repo, erstelle zwei Commits, spalte dann einen Feature‑Branch ab, erzeuge absichtlich einen Merge‑Konflikt und löse ihn. Prüfe jedes Mal mit „git status" und „git log --oneline --graph".
• Visuell lernen: Spiele typische Situationen in Learn Git Branching nach; du siehst sofort, wohin Branch‑Zeiger wandern.
• Offiziell vertiefen: Das kompakte gittutorial und das Buch Pro Git (Deutsch) erklären die Konzepte hinter „Working Directory, Stage, Commit" und die Wirkung zentraler Kommandos konsistent.

Häufige Anfängerfehler – und wie du sie vermeidest

Missverständnisse zu Staging und Committen: Wer „git add" als „Datei einschalten" versteht, stagt oft veraltete Inhalte. Gegenmittel: „git diff" und „git diff --cached" vor jedem Commit.

Branch‑Durcheinander: Auf dem falschen Branch weitergearbeitet? „git switch -c fixup && git cherry-pick <sha>" kann die letzten Commits auf den Ziel‑Branch holen. Besser: vor Beginn „git branch --show-current" prüfen.

Konflikt‑Panik: Konfliktmarker sind normal. Ruhe bewahren, Dateien öffnen, den gewünschten Stand herstellen, stagen, und bei Merge: git commit (in neueren Git‑Versionen alternativ git merge --continue); bei Rebase: git rebase --continue. „git status" führt dich Schritt für Schritt.

Remote‑Probleme: Push verweigert? Erst „git fetch", dann integrieren. Falls der Upstream nicht gesetzt ist: „git push -u origin <branch>" beim ersten Push.

Mini‑Beispiel: Branching und Merging nachvollziehen

Erzeuge ein kleines, prüfbares Szenario, das die Unterschiede sichtbar macht.

# Ausgangslage
git init demo && cd demo
echo "v1" > app.txt
git add app.txt && git commit -m "v1"

# Feature-Branch
git switch -c feature

echo "v2-feature" >> app.txt
git commit -am "Feature ergänzt"

# Parallel auf main
git switch main
echo "v2-main" >> app.txt
git commit -am "Main ergänzt"

# Zusammenführen (echter Merge, kein FF)
git merge feature

# Erwartung: Merge-Commit entsteht; prüfe Historie
git log --oneline --graph --decorate --all

Möchtest du vor dem Merge eine lineare History, ersetze das Zusammenführen durch ein Rebase auf main, solange der Feature‑Branch noch nicht geteilt wurde:

git switch feature
git rebase main
git switch main
git merge feature   # jetzt FF möglich

Du kannst diese Sequenzen in Learn Git Branching nachspielen, um die Bewegung der Zeiger visuell zu sehen.

Fazit und Checkliste

Git wird einfach, wenn du konsequent im Dreieck „Working Directory – Stage – Commit" denkst, Branches als leichte Zeiger begreifst und Merge vs. Rebase nach Zielbild auswählst. Nutze Visualisierung und kleine Übungen, bis die Abläufe sitzen – danach brauchst du seltener die Suchmaschine.

Checkliste für den Alltag:

• Vor dem Commit: „git status", „git diff", „git diff --cached" prüfen; selektiv mit „git add -p" stagen.
• Branch‑Hygiene: früh abzweigen, klar benennen, regelmäßig gegen main rebasen oder mergen.
• Konflikte: „git status" folgen, Dateien bereinigen, „git add", dann bei Rebase: git rebase --continue; bei Merge: git commit.
• Remotes: „git fetch" oft, „git pull" bewusst; non‑fast‑forward erst integrieren, dann pushen.
• Undo bewusst: restore/reset für Working Directory/Stage; revert für geteilte History; reset/rebase nur mit Regelwerk.

Weiterführend und verlässlich: das offizielle gittutorial für den Kurzüberblick und das Buch Pro Git (Deutsch) für das vollständige Verständnis der Konzepte und Werkzeuge.