git add und git commit: Änderungen richtig speichern

Einen „Speichern“-Button gibt es in Git nicht. Änderungen werden in zwei Schritten festgehalten: Zuerst wählt git add aus, welche Änderungen in den nächsten Snapshot kommen, dann schreibt git commit diesen Snapshot in die Historie. Den Zwischenbereich dazwischen nennt man Index oder Staging Area. Genau ihn verstehen viele jahrelang nicht – und genau er macht Commits aussagekräftig.

Drei Zustände einer Datei: Arbeitsverzeichnis, Index, Historie

Jede Änderung durchläuft drei Bereiche:

1. Arbeitsverzeichnis – Sie bearbeiten die Datei im Editor.
2. Index (Stage) – git add legt die aktuelle Version der Datei in den Entwurf des nächsten Commits.
3. Historie – git commit macht aus dem Inhalt des Index einen Commit mit Autor, Datum und Nachricht.

Eine praktische Analogie ist ein Paket. Das Arbeitsverzeichnis ist das Zimmer mit Ihren Sachen, der Index ist der offene Karton, in den Sie legen, was verschickt werden soll, und der Commit ist das zugeklebte, beschriftete Paket. Sie entscheiden selbst, was in den Karton kommt, und müssen nicht alles auf einmal verschicken.

Wozu dient der Index?

Stellen Sie sich vor: Innerhalb einer Stunde haben Sie einen Bug im Login behoben, nebenbei einen Tippfehler in der README korrigiert und mit einem neuen Feature angefangen. Ohne Index landete alles in einem Commit „Diverses“. Mit Index machen Sie drei getrennte Commits, die jeweils leicht zu verstehen, im Review zu prüfen und bei Bedarf zurückzunehmen sind, ohne den Rest anzutasten.

git status: Was ist geändert, was ist vorgemerkt?

Vor jedem add und commit lohnt sich ein Blick auf git status. Es ist der sicherste Git-Befehl überhaupt – er verändert nichts.

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/auth.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/profile.js

• Changes to be committed – bereits im Index, kommt in den Commit;
• Changes not staged – geändert, aber nicht hinzugefügt;
• Untracked files – neue Dateien, die Git noch nicht kennt.

Bei vielen Dateien ist das Kurzformat übersichtlicher:

$ git status -s
M  src/auth.js
 M README.md
?? src/profile.js

Die erste Spalte zeigt den Zustand im Index, die zweite im Arbeitsverzeichnis. M links bedeutet „geändert und hinzugefügt“, rechts „geändert, nicht hinzugefügt“, ?? steht für „nicht versioniert“.

git add: Änderungen zum Index hinzufügen

Ein Synonym für git add ist git stage: Es ist derselbe Befehl, daher auch die Begriffe „Stage“ und „stagen“.

git add -p: nur einen Teil einer Datei hinzufügen

Der am meisten unterschätzte Kniff. Stecken in einer Datei zwei unterschiedliche Änderungen, zeigt git add -p jedes Stück einzeln und fragt, ob es hinzugefügt werden soll:

$ git add -p src/auth.js
@@ -12,7 +12,7 @@ function login(user) {
-  if (user.password = input) {
+  if (user.password === input) {
(1/2) Stage this hunk [y,n,q,a,d,s,e,?]?

y – hinzufügen, n – überspringen, s – in kleinere Stücke aufteilen, q – beenden. So entstehen aus einer Datei zwei saubere Commits.

Prüfen, was genau in den Commit kommt

git diff            # Änderungen, die NOCH NICHT im Index sind
git diff --staged   # was bereits im Index ist und in den Commit kommt

Eine häufige Verwirrung: Nach git add zeigt ein einfaches git diff nichts mehr an. Das heißt nicht, dass die Änderungen verschwunden sind – sie liegen im Index, schauen Sie mit git diff --staged nach (Synonym: --cached).

Eine Datei aus dem Index entfernen (unstage)

git restore --staged file.js

Die Änderungen in der Datei bleiben dabei erhalten, sie ist nur nicht mehr für den Commit vorgemerkt. In älteren Git-Versionen nutzte man dafür git reset HEAD file.js – das funktioniert auch heute noch.

git commit: Änderungen festhalten

git commit -m "Passwortprüfung beim Login korrigieren"

[main 3f2a9c1] Passwortprüfung beim Login korrigieren
 1 file changed, 1 insertion(+), 1 deletion(-)

Die Ausgabe zeigt den Branch, den kurzen Hash des neuen Commits und eine Statistik. In den Commit kommt nur der Inhalt des Index. Haben Sie die Datei nach git add nochmals bearbeitet, sind die neuen Änderungen erst dabei, wenn Sie sie erneut hinzufügen.

Nützliche Optionen von git commit

Ist Vim der Standardeditor und Sie stecken darin fest: Nachricht schreiben, Esc drücken, dann :wq eingeben und Enter. Editor wechseln: git config --global core.editor "code --wait" oder nano.

Eine gute Commit-Message schreiben

Die Nachricht wird ein halbes Jahr später gelesen, wenn jemand herausfinden will, woher ein Bug stammt. Sie sollte beantworten, was und warum geändert wurde – nicht, was ich heute gemacht habe.

• erste Zeile – höchstens 50–72 Zeichen, der Kern der Änderung;
• im Imperativ oder neutral formuliert: „E-Mail-Validierung hinzufügen“, „Fix login redirect“;
• bei Bedarf eine Leerzeile und Details: warum so, welche Einschränkungen es gibt;
• ein Commit – eine logische Änderung.

Schlecht: fix, änderungen, wip, asdf. Gut: Absturz des Warenkorbs bei leerer Produktliste beheben. Viele Teams nutzen das Format Conventional Commits: feat: ..., fix: ..., docs: ....

git commit --amend: den letzten Commit korrigieren

Tippfehler in der Nachricht oder eine Datei vergessen – dafür brauchen Sie keinen neuen Commit „Datei vergessen“. Genau dafür gibt es amend.

Commit-Nachricht ändern

git commit --amend -m "Passwortprüfung beim Login korrigieren"

Vergessene Datei nachträglich hinzufügen

git add forgotten.js
git commit --amend --no-edit

Die Option --no-edit behält die bisherige Nachricht bei.

Wichtig zu amend

--amend „bearbeitet“ den Commit nicht, sondern erzeugt einen neuen mit anderem Hash und ersetzt den alten durch ihn. Solange der Commit nur bei Ihnen existiert, ist das unbedenklich. Haben Sie bereits git push ausgeführt, wird ein normaler Push nach dem amend abgelehnt, und Sie müssen git push --force-with-lease verwenden. In gemeinsam genutzten Branches sollten Sie das lassen: Sie würden eine Historie umschreiben, auf der andere bereits aufbauen.

War das amend ein Versehen, finden Sie den alten Commit in git reflog und kehren mit git reset --soft HEAD@{1} zu ihm zurück.

Typische Fehler

„nothing to commit, working tree clean“

Es gibt keine Änderungen – alles ist schon committet, oder Sie bearbeiten die Datei in einem anderen Ordner. Prüfen Sie git status und den Projektpfad.

„no changes added to commit“

Dateien sind geändert, aber nicht im Index. Führen Sie git add aus oder nutzen Sie git commit -am für bereits versionierte Dateien.

„Please tell me who you are“

Name und E-Mail sind nicht gesetzt. Führen Sie einmalig git config --global user.name "Name" und git config --global user.email "E-Mail" aus.

Zu viel committet

Ist der Commit noch nicht gepusht, nehmen Sie ihn zurück und behalten die Änderungen im Index: git reset --soft HEAD~1. Entfernen Sie dann das Überflüssige mit git restore --staged und committen Sie erneut. Ist ein Secret in den Commit geraten, betrachten Sie es als kompromittiert und stellen Sie es neu aus.

git add . hat Müll hinzugefügt

Richten Sie .gitignore vorab ein und prüfen Sie vor dem Commit git status. Eine bereits versionierte Datei wird erst nach git rm --cached datei nicht mehr verfolgt.

Was ein Commit eigentlich ist

Ein Commit speichert nicht die Differenz zur vorherigen Version, sondern einen Snapshot des gesamten Projekts: einen Verweis auf den Dateibaum, einen Verweis auf den Eltern-Commit, Autor, Datum und Nachricht. Unveränderte Dateien werden nicht kopiert – Git verweist auf bereits gespeicherte Objekte, deshalb belegt die Historie wenig Platz.

Der Commit-Hash (etwa 3f2a9c1) wird aus all diesem Inhalt berechnet. Ändern Sie auch nur einen Buchstaben in der Nachricht, entsteht ein anderer Hash. Darum erzeugen --amend und rebase neue Commits, statt alte zu bearbeiten, und darum kollidiert eine umgeschriebene Historie mit den Kopien Ihrer Kollegen.

Einen kompakten Blick auf die Historie bekommen Sie so:

git log --oneline --graph -10

Jede Zeile ist ein Commit; wenn die Nachrichten in Ihrer Historie verständlich sind, ohne den Diff zu öffnen, machen Sie alles richtig.

Der tägliche Arbeitsablauf

git status                 # was hat sich geändert?
git diff                   # Änderungen ansehen
git add -p                 # Gewünschtes auswählen
git diff --staged          # prüfen, was in den Commit kommt
git commit -m "Verständliche Beschreibung"
git log --oneline -5       # sicherstellen, dass der Commit da ist
git push                   # zum Server übertragen

Ein Commit speichert Änderungen nur lokal. Damit sie auf GitHub oder einem anderen Server landen, braucht es git push.

Fazit

git add stellt den nächsten Snapshot im Index zusammen, git status und git diff --staged zeigen, was hineinkommt, und git commit schreibt den Snapshot in die Historie. Machen Sie kleine, logische Commits mit verständlichen Nachrichten und nutzen Sie für kleine Korrekturen am letzten Commit git commit --amend – vor dem Push. Der Index und das zweistufige Schema add → commit werden im Git-Kurs praktisch durchgearbeitet.