git add

Beschreibung

Der Befehl git add fügt Änderungen aus dem Arbeitsverzeichnis zur Staging-Area (auch Index genannt) hinzu. Damit teilst du Git mit, welche Dateiänderungen du in den nächsten Commit aufnehmen möchtest. git add speichert nichts in der Geschichte — es markiert Änderungen lediglich als bereit. Um sie tatsächlich aufzuzeichnen, führst du anschließend git commit aus. Um zu prüfen, was gestagt und was nicht gestagt ist, verwendest du git status.

Diese Seite erläutert, was git add tut, die drei Git-„Bereiche", zwischen denen es sich befindet, die nützlichsten Optionen sowie den interaktiven Modus und den Patch-Bearbeitungsmodus zum schrittweisen Stagen von Änderungen.

Die drei Bereiche

Jede Änderung in einem Git-Projekt durchläuft drei Bereiche:

• Arbeitsverzeichnis — die Dateien, die du tatsächlich auf der Festplatte bearbeitest.
• Staging-Area (Index) — ein Snapshot dessen, was in den nächsten Commit einfließt.
• Repository — die committete Geschichte, die von git commit geschrieben wird.

git add verschiebt Änderungen aus dem Arbeitsverzeichnis in die Staging-Area. git commit schreibt dann alles, was gestagt ist, in das Repository. Dieser zweistufige Ablauf ermöglicht es dir, ein unübersichtliches Arbeitsverzeichnis in saubere, fokussierte Commits aufzuteilen.

Warum überhaupt Änderungen stagen?

In vielen Versionskontrollsystemen speichert ein Commit alles, was du geändert hast. Git fügt die Staging-Area absichtlich dazwischen ein, damit du genau bestimmen kannst, was jeder Commit enthält. Dies ist nützlich, wenn du mehrere nicht zusammenhängende Dinge gleichzeitig bearbeitet hast: Du kannst eine logische Änderung stagen und committen, dann die nächste stagen und committen, und so deine Geschichte lesbar halten.

Da das Stagen einen Snapshot zum Zeitpunkt der Ausführung erstellt, muss git add erneut ausgeführt werden, wenn du weitere Änderungen vorgenommen hast, die einbezogen werden sollen. Wenn du eine Datei stagst und sie danach weiter bearbeitest, bleiben die späteren Änderungen ungestagt, bis du erneut git add ausführst.

Häufige Optionen

Eine einzelne Datei für den nächsten Commit stagen:

git add <file>

Alle Änderungen innerhalb eines Verzeichnisses stagen (rekursiv, einschließlich neuer Dateien):

git add <directory>

Alle Änderungen im gesamten Repository stagen — neue, geänderte und gelöschte Dateien:

git add -A

Änderungen an bereits verfolgten Dateien stagen, einschließlich Löschungen, aber neue, nicht verfolgte Dateien ignorieren:

git add -u

Änderungen interaktiv stagen, Teile von Dateien Hunk für Hunk auswählen:

git add -p

git add . vs git add -A vs git add -u

Diese drei werden leicht verwechselt, daher lohnt es sich, genau zu sein:

In modernem Git stagen sowohl git add . als auch git add -A Löschungen; der Unterschied besteht nur im Pfadgeltungsbereich. Verwende -u, wenn du Wegwerfsdateien erstellt hast, die du nicht committen möchtest, und es vorziehst, sie nicht in .gitignore aufzuführen.

Beispiele für git add

Du kannst diese Befehle in jedem Git-Repository ausführen. Beginne damit, den aktuellen Zustand mit git status zu prüfen, dann stagen und committen.

Eine neue Datei stagen

git add hello.py

Mehrere bestimmte Dateien auf einmal stagen

git add hello.py utils.py README.md

Alles stagen und dann mit einer Nachricht committen

git add -A
git commit -m "Add greeting script"

Sehen, was vor dem Committen gestagt ist

git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   hello.py

Um eine Datei aus der Staging-Area zurückzuholen, ohne deine Änderungen zu verlieren, verwende git restore --staged (oder in älteren Git-Versionen git reset):

git restore --staged hello.py

Interaktiver Modus

Das Ausführen von git add -p (oder die Auswahl der Patch-Option aus git add -i) startet eine interaktive Staging-Sitzung. Git zeigt dir einen Hunk — einen Block geänderter Zeilen — nach dem anderen und fragt nach einem Befehl. Die häufigsten Antworten sind:

• y - diesen Hunk stagen
• n - diesen Hunk nicht stagen
• q - beenden; diesen Hunk und alle verbleibenden nicht stagen
• a - diesen Hunk und alle späteren Hunks in der Datei stagen
• d - diesen Hunk und alle späteren Hunks in der Datei nicht stagen
• g - einen Hunk auswählen, zu dem gewechselt werden soll
• / - nach einem Hunk suchen, der dem angegebenen Regex entspricht
• j - diesen Hunk unentschieden lassen, zum nächsten unentschiedenen Hunk wechseln
• J - diesen Hunk unentschieden lassen, zum nächsten Hunk wechseln
• k - diesen Hunk unentschieden lassen, zum vorherigen unentschiedenen Hunk wechseln
• K - diesen Hunk unentschieden lassen, zum vorherigen Hunk wechseln
• s - den aktuellen Hunk in kleinere Hunks aufteilen
• e - den aktuellen Hunk manuell bearbeiten
• ? - Hilfe anzeigen

Das Aufteilen (s) ist besonders praktisch: Wenn Git zwei nicht zusammenhängende Änderungen als einen Hunk präsentiert, teilt s ihn auf, sodass du nur den gewünschten Teil stagen kannst. Dies ist der alltägliche Weg, einen sauberen Commit aus einer Datei mit gemischten Änderungen zu erstellen.

Patches bearbeiten

Der Aufruf von git add -e oder die Auswahl von e aus dem interaktiven Chunk-Selektor öffnet einen Patch in deinem Editor. Nach dem Verlassen des Editors wird die Ausgabe auf den Index angewendet. Du kannst beliebige Änderungen am Patch vornehmen, aber einige Bearbeitungen können zu komplexen Ausgaben führen oder den Patch sogar unanwendbar machen. Wenn du den Vorgang vollständig ablehnen möchtest, lösche einfach alle Zeilen des Patches. Hier sind einige häufige Elemente, die du in einem Patch sehen kannst, und welche Bearbeitungsoperationen dafür sinnvoll sind.

Zeilen, die mit + beginnen, stellen hinzugefügten Inhalt dar. Du kannst sie löschen, um das Stagen hinzugefügter Zeilen zu verhindern.

Zeilen, die mit - beginnen, stellen entfernten Inhalt dar. Um das Stagen ihrer Löschung zu verhindern, kannst du das - in ein Leerzeichen ( ) umwandeln.

Geänderter Inhalt wird mit --Zeilen (Löschen des alten Inhalts) gefolgt von +-Zeilen (Hinzufügen des Ersatzinhalts) dargestellt. Um das Stagen der Änderung zu verhindern, wandle die --Zeilen in Leerzeichen um und entferne die +-Zeilen. Beachte, dass die Bearbeitung nur einer Hälfte des Paares zu verwirrenden Änderungen im Index führen kann.

Häufige Fallstricke

• Staging ist ein Snapshot, kein Live-Link. Wenn du git add für eine Datei ausführst und sie dann erneut bearbeitest, ist nur die frühere Version gestagt. Führe git add erneut aus, um die neuen Änderungen einzuschließen — git status zeigt dann die gleiche Datei sowohl unter „Changes to be committed" als auch unter „Changes not staged for commit" an.
• git add löscht keine Dateien für dich. Es stagt Löschungen bereits verfolgter Dateien (mit -A oder -u), aber um eine Datei sowohl von der Festplatte zu löschen als auch diese Löschung in einem Schritt zu stagen, verwende git rm.
• Ignorierte Dateien bleiben ignoriert. Muster in .gitignore werden von git add . nicht gestagt. Um eine ignorierte Datei zwangsweise hinzuzufügen, übergib git add -f <file>.
• Noch ist nichts dauerhaft. Das Stagen ist vollständig umkehrbar. Verwende git restore --staged <file>, um vor dem Commit das Staging rückgängig zu machen.

Übung