Übersicht

git add [-p] [-A] [-u] [--] [<pathspec>...]

Beschreibung

Der git add-Befehl bewegt Änderungen aus Ihrem Working Tree in die Staging Area (auch Index genannt). Die Staging Area ist ein Snapshot dessen, was in den nächsten Commit fließen wird. Indem Sie Änderungen explizit stagen, lässt Git Sie Commits zusammenstellen, die genau die Arbeit enthalten, die Sie aufzeichnen wollen — auch wenn Ihr Working Tree andere unzusammenhängende laufende Bearbeitungen hat.

git add kann ganze Dateien, Teile von Dateien (mit -p) oder Verzeichnisse stagen. Es committet nichts; es aktualisiert nur den Index. Der häufigste Workflow ist: bearbeiten, git status, git add, git commit. git add zu meistern, besonders seine interaktiven Modi, ist eine der besten Möglichkeiten, Ihre Commit-Historie lesbar und leicht reviewbar zu machen.

Im täglichen Einsatz integriert sich git add eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git add --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git add mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git add hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
-A, --all	Staged alle Änderungen im Working Tree, einschließlich Löschungen und neuer Dateien.
-u, --update	Staged nur Modifikationen und Löschungen verfolgter Dateien — ignoriert neue Dateien.
-p, --patch	Wählt interaktiv Hunks von Änderungen zum Stagen aus.
-n, --dry-run	Zeigt, was gestaged würde, ohne tatsächlich zu stagen.
-f, --force	Fügt Dateien hinzu, auch wenn sie auf .gitignore passen.
-i, --interactive	Öffnet eine menügesteuerte Oberfläche zum Stagen.
--intent-to-add / -N	Zeichnet die Absicht auf, eine Datei hinzuzufügen, sodass deren Diff erscheint.

Beispiele

git add README.md src/main.c
    # Zwei bestimmte Dateien stagen

    git add -A
    # Alles stagen: neue, geänderte und gelöschte Dateien

    git add -p
    # Stücke interaktiv überprüfen und Stück für Stück stagen

    git add 'src/**/*.js'
    # Alle JavaScript-Dateien unter src per Pathspec stagen

Häufige Fehler

Blindes git add . staget oft Dateien, die Sie nicht beabsichtigt haben — Logdateien, Build-Artefakte, geheime Schlüssel. Verwenden Sie zuerst git status und ziehen Sie -p für sensible Änderungen in Betracht. Eine weitere häufige Verwirrung: git add -u erfasst keine neuen Dateien, während git add . dies tut. Wenn Sie eine Datei nach dem Stagen erneut ändern, sind diese folgenden Bearbeitungen nicht gestaged, bis Sie git add erneut ausführen.

Verwandte Befehle

git commit, git status, git restore, git reset