Committen — was es ist, Formatierungsregeln und Arbeiten mit Git

Was ist ein Commit in Git

Ein Commit in Git ist ein Objekt, das den Zustand der Projektdateien zu einem bestimmten Zeitpunkt speichert. Jeder Commit enthält einen Snapshot aller verfolgten Dateien, einen Verweis auf den übergeordneten Commit und Metadaten. Im Gegensatz zu anderen Versionskontrollsystemen verwendet Git Content-addressable Storage — jedes Objekt wird durch einen SHA-1-Hash seines Inhalts identifiziert.

Wenn ein Entwickler Änderungen committed, erstellt Git ein Commit-Objekt, das Folgendes speichert: ein Tree-Objekt (Dateistruktur), Parent-Commit-Hash, Autor, Committer, Datum und Nachricht. Dieses Objekt ist unveränderlich — nach der Erstellung kann ein Commit nicht geändert werden, ohne seinen Hash zu verändern. Diese Unveränderlichkeit garantiert die Integrität des Projektverlaufs.

# Änderungen stagen und committen
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Commit-Details anzeigen
git log --oneline -3
git show HEAD

# Alle Änderungen stagen und in einem Schritt committen
git commit -a -m "Update dependencies to latest versions"

Commits bilden einen gerichteten azyklischen Graphen (DAG), bei dem jeder neue Commit auf den vorherigen verweist. Dies ermöglicht die Navigation durch den Verlauf, das Rückgängigmachen von Änderungen und die Analyse der Entwicklung der Codebasis. Das Verständnis der Struktur des Git-DAG ist die Grundlage für die fortgeschrittene Arbeit mit Commits.

Wie man Änderungen richtig committed

Der Commit-Prozess in Git besteht aus zwei Phasen: Hinzufügen von Änderungen zur Staging-Area (Index) und Erstellen des Commits. Die Staging-Area ermöglicht es dem Entwickler, auszuwählen, welche spezifischen Änderungen in den Commit aufgenommen werden sollen, auch wenn viele Dateien im Arbeitsverzeichnis geändert wurden.

Die Atomaritätsregel ist das Schlüsselprinzip eines guten Commits. Jeder Commit sollte eine logische Änderung enthalten. Wenn ein Entwickler einen Bug behebt und Code refaktorisiert — sollten dies zwei verschiedene Commits sein. Atomare Commits vereinfachen Code-Reviews, das Rückgängigmachen von Änderungen und die Analyse des Verlaufs.

Vor dem Committen sollte man überprüfen, ob noch Debug-Ausgaben, auskommentierte Blöcke oder versehentliche Änderungen im Code vorhanden sind. Dazu wird der Befehl git diff --cached verwendet, der anzeigt, was genau in den Commit aufgenommen wird. Eine zusätzliche Überprüfung mit git status zeigt die Liste der Dateien in der Staging-Area an.

• Änderungen prüfen — git diff --cached zeigt, was in den Commit aufgenommen wird
• Qualität prüfen — Code sollte vor dem Commit Linter und Tests bestehen
• Nachricht schreiben — eine klare Beschreibung des Zwecks der Änderung
• Gestagte Dateien prüfen — git status bestätigt die Dateiliste

Regeln zum Schreiben von Commit-Nachrichten

Die Commit-Nachricht ist die Dokumentation der Änderung für zukünftige Entwickler. Eine gute Nachricht beantwortet die Fragen: Was wurde geändert und warum. Die Conventional Commits-Konvention (Angular-Team, 2016) ist zum Standard für viele Projekte geworden und definiert das Format: Typ(Bereich): Beschreibung.

Eine gute Commit-Nachricht besteht aus einem Header (bis zu 50 Zeichen) und einem Body (optional, bis zu 72 Zeichen pro Zeile). Der Header wird im Imperativ geschrieben: „Add“, nicht „Added“ oder „Adds“. Capitalization und ein Punkt am Ende des Headers werden nicht verwendet — dies ist eine internationale Git-Konvention.

Eine schlechte Nachricht: „fix things“ oder „update“ — sie trägt keine Information. In einem Monat wird ein Entwickler nicht verstehen können, was genau geändert wurde und warum. Eine gute Nachricht: „fix(payment): handle timeout in stripe callback“ — sofort ist klar, was und wo behoben wurde.

Häufige Fehler beim Committen

Entwickler, insbesondere Anfänger, machen beim Committen häufig typische Fehler. Der häufigste ist ein zu großer Commit, der Dutzende von Änderungen vermischt. Ein solcher Commit kann nicht teilweise rückgängig gemacht werden, und das Code-Review wird zur Qual.

Der zweithäufigste Fehler ist eine schlechte Commit-Nachricht. Nachrichten wie „fix“, „update“, „changes“ oder „wip“ liefern zukünftigen Entwicklern keinen Kontext. In sechs Monaten wird sich niemand mehr daran erinnern, was genau behoben wurde. Die Regel ist einfach: Stellen Sie sich vor, Sie schauen in einem Jahr in den Verlauf und versuchen, eine bestimmte Änderung zu finden.

Der dritte Fehler ist das Committen von nicht kompiliertem oder nicht funktionierendem Code. Nach einem Commit sollte der Code zumindest kompilieren. Den Build nicht brechen ist eine grundlegende Anforderung an jeden Commit in einem gemeinsamen Branch. Dazu werden vor dem Commit der Build und die Tests ausgeführt.

Der vierte Fehler ist das Committen von vertraulichen Daten. API-Schlüssel, Passwörter und Tokens sollten nicht in die Git-Historie gelangen. Wenn ein Geheimnis bereits committed wurde, reicht es nicht aus, es in einem neuen Commit zu entfernen, sondern es muss aus der gesamten Historie mittels git filter-branch oder BFG Repo-Cleaner gelöscht werden.

Fortgeschrittene Techniken für die Arbeit mit Commits

Git bietet Werkzeuge zur Verwaltung des Commit-Verlaufs. Eines der nützlichsten ist git commit --amend, mit dem der letzte Commit um neue Änderungen ergänzt oder die Nachricht korrigiert werden kann. Dies ist praktisch, wenn der Entwickler vergessen hat, eine Datei einzuschließen oder einen Tippfehler in der Nachricht gemacht hat.

# Letzte Commit-Nachricht korrigieren
git commit --amend -m "fix(auth): correct token validation logic"

# Vergessene Datei zum letzten Commit hinzufügen
git add missed-file.txt
git commit --amend --no-edit

# Interaktives Rebase für die letzten 3 Commits
git rebase -i HEAD~3

Interaktives Rebase ist ein mächtiges Werkzeug zum Umschreiben des Verlaufs. Es ermöglicht das Kombinieren von Commits (squash), das Ändern von Nachrichten (reword), das Neuanordnen (reorder) und das Löschen von Commits (drop). Allerdings ändert Rebase den Verlauf, daher wird es nur auf lokale Commits angewendet, die noch nicht in ein entferntes Repository gepusht wurden.

Es gibt zwei Ansätze zum Rückgängigmachen von Commits. git revert erstellt einen neuen Commit, der die Änderungen des vorherigen rückgängig macht — eine sichere Methode, die den Verlauf bewahrt. git reset entfernt Commits aus dem Verlauf — gefährlich, wenn die Commits bereits gepusht wurden. In der Teamarbeit wird nur git revert verwendet, um veröffentlichte Commits rückgängig zu machen.