Mit dem Befehl git commit erfasst du einen Snapshot der aktuellen Änderungen aus der Staging-Umgebung des Projekts. Committete Snapshots gelten als "sichere" Versionen eines Projekts – Git nimmt an ihnen nur auf explizite Anweisung hin Änderungen vor. Vor dem Ausführen von git commit wird der Befehl git add eingesetzt, um Änderungen, die in einem Commit gespeichert werden sollen, in das Projekt zu befördern oder zu "stagen". git commit und git add sind zwei der meistgenutzten Git-Befehle.

"git commit" im Vergleich mit "svn commit"

Die Befehle git commit und svn commit heißen zwar ähnlich, haben aber sonst nichts gemeinsam. Die Namensähnlichkeit kann bei Git-Neulingen, die zuvor mit SVN gearbeitet haben, für Verwirrung sorgen. Daher ist es wichtig, die Unterschiede zu erklären. Beim Vergleich zwischen git commit und svn commit ist zu beachten, dass es sich bei SVN um ein zentralisiertes Anwendungsmodell handelt, bei Git dagegen um ein verteiltes. Bei SVN werden mit einem Commit Änderungen aus dem lokalen SVN-Client in ein zentrales, gemeinsam genutztes SVN-Remote-Repository gepusht. Bei Git sind die Repositorys dagegen verteilt, und Snapshots werden per Commit in das lokale Repository übertragen, ohne dass irgendeine Interaktion mit anderen Git-Repositorys erforderlich ist. Git-Commits können später in beliebige Remote-Repositorys gepusht werden.

Wie es funktioniert

Grob gesagt kann Git als Hilfsmittel zum Verwalten von Zeitleisten betrachtet werden. Commits bilden die Grundbausteine einer Git-Projektzeitleiste. Sie sind quasi Snapshots oder Meilensteine in der Zeitleiste eines Git-Projekts. Commits werden mit dem Befehl git commit erstellt, der den Zustand eines Projekts zu diesem exakten Zeitpunkt erfasst. Git-Snapshots werden immer in das lokale Repository committet. Damit unterscheidet sich dieser Workflow grundlegend von SVN, bei dem die Arbeitskopie in das zentrale Repository committet wird. Wenn du mit Git arbeitest, entscheidest du selbst, wann du mit dem zentralen Repository interagieren möchtest. Genauso wie die Staging-Umgebung als Puffer zwischen dem Arbeitsverzeichnis und dem Projektverlauf fungiert, fungiert das lokale Repository eines Entwicklers als Puffer zwischen seinen Codebeiträgen und dem zentralen Repository.

Somit ist das Entwicklungsmodell für Git-Benutzer ein grundlegend anderes. Statt eine Änderung vorzunehmen und diese direkt in das zentrale Repository zu committen, haben Entwickler mit Git die Möglichkeit, Commits in ihrem lokalen Repository anzusammeln. Dies hat im Vergleich zur SVN-basierten Zusammenarbeit viele Vorteile: Es ist einfacher, ein Feature in kleinste Commits aufzuteilen, zusammengehörige Commits in Gruppen zusammenzufassen und den lokalen Verlauf zu bereinigen, bevor er im zentralen Repository veröffentlicht wird. Außerdem können Entwickler in isolierten Umgebungen arbeiten und die Integration bis zu einem passenden Punkt aufschieben, an dem sie bereit zum Merge mit anderen Benutzern sind. Isolation und eine verzögerte Integration sind zwar für die einzelnen Entwickler von Vorteil, aber im Team empfiehlt es sich dennoch, häufige Integrationen von jeweils kleinen Einheiten durchzuführen. Wenn du an weiteren Informationen über Best Practices für die Teamzusammenarbeit mit Git interessiert bist, lies, wie Teams ihren Git-Workflow strukturieren.

Snapshots statt Diffs

SVN und Git unterscheiden sich nicht nur in der praktischen Ausführung. Auch ihre zugrunde liegenden Implementierungen haben vollkommen unterschiedliche Designansätze. SVN verfolgt Unterschiede zwischen verschiedenen Dateiversionen, während das Versionskontrollmodel von Git auf Snapshots basiert. Ein Beispiel: Ein SVN-Commit umfasst Unterschiede zur ursprünglich zum Repository hinzugefügten Datei. Git andererseits zeichnet in jedem Commit den gesamten Inhalt jeder Datei auf.

Git-Tutorial: Snapshots statt Diffs

Git-Vorgänge werden hierdurch viel schneller als mit SVN, da eine einzelne Dateiversion nicht anhand von Diffs "zusammengestellt" werden muss. Die vollständige Überarbeitung jeder Datei ist unmittelbar über die Git-interne Datenbank verfügbar.

Das Snapshot-Modell von Git hat weitreichende Auswirkungen auf nahezu alle Aspekte des Versionskontrollmodells, angefangen bei den Branching- und Merging-Tools bis hin zu den Workflows zur Zusammenarbeit.

Allgemeine Optionen

git commit

Mit diesem Befehl committest du einen Snapshot im Staging-Bereich. Ein Texteditor wird geöffnet, der dich dazu auffordert, eine Commit-Nachricht einzugeben. Speichere nach der Eingabe die Datei, und schließe den Editor, um den eigentlichen Commit zu erstellen.

git commit -a

Mit diesem Befehl committest du einen Snapshot aller Änderungen im Arbeitsverzeichnis. Eingeschlossen werden nur Änderungen an verfolgten Dateien (d. h. an Dateien, die zu irgendeinem Zeitpunkt ihres Lebenszyklus per git add hinzugefügt wurden).

git commit -m "commit message"

Ein Befehlskürzel, das sofort einen Commit mit einer angegebenen Commit-Nachricht erstellt. Standardmäßig öffnet git commit den lokal konfigurierten Texteditor und fordert dich zur Eingabe einer Commit-Nachricht auf. Mit der Option -m wird statt der Texteditor-Eingabeaufforderung eine Inline-Nachricht verwendet.

git commit -am "commit message"

Ein Befehlskürzel für Power-User, bei dem die Optionen -a und -m miteinander kombiniert werden. So wird sofort ein Commit aller Änderungen aus der Staging-Umgebung erstellt und eine Inline-Commit-Nachricht erfasst.

git commit --amend

Mit dieser Option wird dem Commit-Befehl eine weitere Funktionsebene hinzugefügt. Wenn du diese Option angibst, wird der letzte Commit geändert. Statt einen neuen Commit zu erstellen, werden die Änderungen aus der Staging-Umgebung dem vorherigen Commit hinzugefügt. Dieser Befehl öffnet den im System konfigurierten Texteditor und fordert dich zum Ändern der zuvor angegebenen Commit-Nachricht auf.

Beispiele

Speichern von Änderungen mit einem Commit

Im folgenden Beispiel nehmen wir an, dass du einige der Inhalte in einer Datei namens hello.py im aktuellen Branch bearbeitet hast und jetzt für einen Commit in den Projektverlauf bereit bist. Zunächst musst du die Datei mit git add in die Staging-Umgebung verschieben. Anschließend kannst du den Snapshot aus der Staging-Umgebung committen.

git add hello.py

Mit diesem Befehl wird hello.py in die Staging-Umgebung von Git aufgenommen. Um uns das Ergebnis dieser Aktion anzusehen, verwenden wir den Befehl git status.

git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
  new file: hello.py

Der in grün angezeigte Output "new file: hello.py" gibt an, dass hello.py zusammen mit dem nächsten Commit gespeichert wird. Den Commit kannst du mit folgendem Befehl erstellen:

git commit

Ein Texteditor wird geöffnet (anpassbar über git config). Du wirst aufgefordert, eine Commit-Protokollnachricht einzugeben, und siehst eine detaillierte Liste des Commit-Inhalts:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
#modified: hello.py

Für Commit-Nachrichten in Git ist keine bestimmte Formatierung erforderlich, es ist aber allgemein üblich, den gesamten Commit in der ersten Zeile in weniger als 50 Zeichen zusammenzufassen. Darauf folgt eine Leerzeile und anschließend eine ausführliche Erklärung der Änderungen. Ein Beispiel:

Change the message displayed by hello.py
- Update the sayHello() function to output the user's name - Change the sayGoodbye() function to a friendlier message

Üblicherweise wird die erste Zeile der Commit-Nachricht ähnlich wie bei einer E-Mail als Betreffzeile genutzt. Der Rest der Protokollnachricht ist dann der Textkörper, in dem Details zum Commit-Changeset festgehalten werden. Viele Entwickler bevorzugen in ihren Commit-Nachrichten das Präsens. So lesen sich die Nachrichten eher wie Aktionen im Repository, wodurch viele der Vorgänge zum Umarbeiten des Verlaufs intuitiver werden.
 

Aktualisieren (Ändern) von Commits

Wir fahren mit dem hello.py-Beispiel von oben fort. Als Nächstes nehmen wir weitere Aktualisierungen an hello.py vor und führen dann Folgendes aus:

git add hello.py
git commit --amend

Auch hier wird der konfigurierte Texteditor geöffnet. Dieses Mal ist allerdings die zuvor eingegebene Commit-Nachricht bereits vorausgefüllt. Daraus können wir schließen, dass wir keinen neuen Commit erstellen, sondern den letzten Commit bearbeiten.

Zusammenfassung

Der Befehl git commit ist eine der wichtigsten Funktionen von Git. Bevor du git add verwenden kannst, musst du die Änderungen auswählen, die für den nächsten Commit in die Staging-Umgebung aufgenommen werden sollen. Dann erstellst du mit git commit einen Snapshot der Änderungen aus der Staging-Umgebung entlang einer Zeitleiste des Git-Projektverlaufs. Weitere Informationen über die Verwendung von git add findest du auf der entsprechenden Seite. Mit dem Befehl git status kannst du den Zustand der Staging-Umgebung und des ausstehenden Commits abrufen.

Die Commit-Modelle sind bei SVN und Git sehr unterschiedlich, werden aber aufgrund der gemeinsamen Terminologie oft verwechselt. Wenn du bisher SVN genutzt hast und jetzt auf Git umstellst, wird es dich freuen, dass Commits bei Git nicht aufwendig sind und häufig genutzt werden sollten. Bei SVN dagegen sind Commits ein komplexer Vorgang. SVN-Commits erfordern eine Remote-Anfrage, während Git-Commits lokal und mit einem effizienteren Algorithmus erfolgen.

Möchtest du Git kennenlernen?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen