Einführung

Der Index ist eine Binärdatei unter .git/index, die ein Tree-Objekt spiegelt: eine sortierte Liste von Pfaden mit Modus, Hash und Stat-Informationen. Er ist die Staging Area für den nächsten Commit und ein Cache, der es Git erlaubt, das erneute Hashen unveränderter Dateien zu überspringen.

Inspizieren

git ls-files --stage
# 100644 a1b2c3...  0  README.md
# 100644 e4f5g6...  0  src/main.c

Stage 0 bedeutet "kein Konflikt". Während eines Merges erhalten konfliktbehaftete Pfade die Stages 1 (Basis), 2 (ours), 3 (theirs).

Was Stat-Caching bringt

Der Index speichert auch ctime, mtime, Größe und Inode für jeden Pfad. git status vergleicht diese mit dem Working Tree, bevor er hasht; bei Übereinstimmung gilt die Datei als unverändert. Deshalb ist git status auf riesigen Bäumen schnell.

git update-index --refresh
git update-index --really-refresh

Den Index modifizieren

git add file.txt                  # aus Working Tree stagen
git rm --cached file.txt          # aus Index entfernen, auf Festplatte behalten
git restore --staged file.txt     # unstagen
git update-index --chmod=+x bin/run   # Executable-Bit ändern

assume-unchanged und skip-worktree

Zwei Flags sagen Git, bestimmte Pfade zu ignorieren:

git update-index --assume-unchanged config.local
git update-index --skip-worktree config.local

• assume-unchanged: ein Performance-Hinweis; Git kann Änderungen trotzdem bemerken.
• skip-worktree: stärker; gedacht für Dateien, die der Nutzer lokal modifiziert lässt.

Keiner ersetzt .gitignore; beide sind Workspace-lokale Hacks, nicht teilbar.

Trees lesen und schreiben

git write-tree                # Index als Tree-Objekt einfrieren
git read-tree HEAD            # Index auf einen Tree zurücksetzen
git read-tree --reset -u HEAD # auch Working Tree aktualisieren

Diese Plumbing-Befehle liegen commit, checkout und merge zugrunde.

Konflikte im Index

Während eines Merges wird der Index zur Wahrheitsquelle dafür, was ungelöst ist:

git ls-files -u
# 100644 a1...  1  src/main.c
# 100644 b2...  2  src/main.c
# 100644 c3...  3  src/main.c

Einen Konflikt zu lösen bedeutet, den finalen Inhalt zu schreiben und mit git add hinzuzufügen, wodurch alles zu einem einzigen Stage-0-Eintrag zusammenfällt.

Sparse-Checkout und der Sparse-Index

Sparse-Checkout befüllt den Working Tree mit nur einer Teilmenge des Repository-Trees, nützlich in Monorepos. Mit Cone-Modus plus dem Sparse-Index schrumpft auch der Index selbst auf den aktiven Cone, was Operationen auf riesigen Repositories schnell macht:

git sparse-checkout init --cone
git sparse-checkout set src/myteam docs
git sparse-checkout list
git sparse-checkout disable

Der Sparse-Index markiert ausgelassene Einträge mit einem speziellen Bit, sodass Git sie faul nur erweitern kann, wenn Befehle es brauchen. Diese Funktion erfordert Git 2.32 oder neuer für volle Funktionalität.

Häufige Fehler

Glauben, der Index sei nur "was gestaged ist". Er ist auch ein Cache und Konflikt-Tracker. .git/index löschen, wenn man feststeckt; bauen Sie ihn mit git read-tree HEAD neu, aber Sie verlieren jedes uncommitted Staging. --assume-unchanged als Ersatz für .gitignore verwenden; der nächste Klon wird es nicht respektieren. Schließlich: Erwarten, dass der Index leere Verzeichnisse verfolgt; das kann er nicht. Verwenden Sie eine Platzhalterdatei (.gitkeep), wenn Sie einen leeren Ordner committen müssen.