Commit: Ein gespeicherter Stand im Repository – einfach erklärt

Ein Commit ist in der Versionsverwaltung Git ein festgeschriebener Stand des Projekts. Er hält fest, welche Änderungen wann von wem mit welcher Begründung gemacht wurden. Eine Kette von Commits bildet die Historie eines Projekts.

Der Ablauf: erst stagen, dann committen

Git kennt drei Bereiche: Arbeitsverzeichnis, Staging-Bereich (Index) und Repository. Nur was im Index liegt, landet im Commit.

git status                     # Was ist geändert?
git add src/login.py           # Änderung in den Index legen
git add -p                     # Änderungen stückweise auswählen
git commit -m "Login: Rate-Limit ergänzt"

# Kurzform für bereits verfolgte Dateien
git commit -am "Tippfehler in Doku korrigiert"

Was in einem Commit steckt

  • ein Hash – die eindeutige ID, historisch SHA-1, zunehmend SHA-256
  • ein Verweis auf den Eltern-Commit (bei Merges auf mehrere)
  • Autor und Committer mit Zeitstempel
  • die Commit-Nachricht
  • ein Verweis auf den Baum (Tree) der Dateien und Ordner

Weil jeder Commit auf seinen Vorgänger verweist, lässt sich jeder frühere Stand exakt rekonstruieren – das ist der Kern von Versionierung.

Guter Stil

  • Atomar: ein Commit = eine logische Änderung.
  • Aussagekräftig: „Login: Rate-Limit ergänzt" statt „fix".
  • Imperativ im Betreff, Details im Body.
  • Konventionen wie Conventional Commits (feat:, fix:, docs:) erlauben automatische Changelogs.

Änderungen zurücknehmen

git commit --amend             # letzten Commit nachbessern
git revert <hash>              # Gegen-Commit erzeugen (Historie bleibt)
git reset --soft HEAD~1        # letzten Commit auflösen, Änderungen behalten

Faustregel: revert für alles, was bereits geteilt wurde – reset nur für lokale, noch nicht gepushte Commits. Wer die Historie umschreibt, zwingt alle anderen zu Nacharbeit.

Siehe auch