Diese Tutorial-Reihe widmet sich den Grundlagen des verteilten Versionskontrollsystems Git. Nachdem die ersten Artikel beschrieben haben, wie Git initial aufgesetzt wird, erläutern wir nun, wie Änderungen vorgenommen und gespeichert werden. Beitrag eins hat den Befehl git add behandelt, der eng mit git commit zusammenspielt.

git commit

Der Befehl git commit committet den Snapshot im Staging-Bereich in die Projekt-Historie. Solche committeten Snapshots kann man sich als "sichere" Versionen eines Projekts vorstellen: Git wird sie niemals ändern, wenn es dem System nicht explizit gesagt wird. Zusammen mit git add handelt es sich um eines der wichtigsten Git-Kommandos.

Trotz der Namensähnlichkeit ist git commit etwas ganz anderes als svn commit. Snapshots werden in das lokale Repository committet, und dies erfordert absolut keine Interaktion mit anderen Git-Repos.

Nutzung

git commit

Den Snapshot im Staging-Bereich committen. Ein Text-Editor wird geöffnet, der vom Entwickler eine Commit-Nachricht erwartet. Nach der Eingabe sichert er die Datei und schließt den Editor, um den tatsächlichen Commit zu erzeugen.

git commit -m "<nachricht>"

Den Snapshot im Staging-Bereich committen. Statt den Text-Editor zu öffnen, wird <nachricht> als Commit-Nachricht verwendet.

git commit -a

Einen Snapshot aller Änderungen im Arbeitsverzeichnis committen. Dies beinhaltet nur Modifizierungen in getrackten Dateien, also solchen, die irgendwann mit git add hinzugefügt wurden.

Hinweise

Snapshots werden immer in das lokale Repository committet. Darin unterscheidet sich Git grundsätzlich von SVN, wo die Arbeitskopie in das zentrale Repo committet wird. Git dagegen zwingt den Entwickler nicht zur Interaktion mit dem zentralen Repo, ehe er nicht bereit dafür ist. So wie der Staging-Bereich einen Puffer zwischen Arbeitsverzeichnis und Projekt-Historie bildet, fungiert jedes lokale Repository eines Entwicklers als Puffer zwischen seinen Änderungen und dem zentralen Repo.

Damit ändert sich für Git-Nutzer das eigentliche Entwicklungsmodell. Statt eine Änderung vorzunehmen und sie direkt in das zentrale Repo zu committen, haben Git-Entwickler die Möglichkeit, Commits in ihrem lokalen Repo zu akkumulieren. Das hat gegenüber der Zusammenarbeit nach dem SVN-Modell viele Vorteile: Insbesondere ist es einfacher, ein Feature in kleinstmögliche Commits aufzuspalten, zusammengehörende Commits zusammen gruppiert zu halten und die lokale Historie aufzuräumen, ehe etwas in das zentrale Repo übertragen wird. Zudem können Entwickler in ihrer isolierten Umgebung arbeiten und müssen keine Integration vornehmen, ehe sie den geeigneten Punkt erreicht haben.

Snapshots statt Diffs

Abgesehen von den praktischen Differenzierung zwischen SVN und Git, folgen auch die zugrundeliegenden Implementierungen verschiedenen Design-Philosophien. Während SVN Unterschiede auf Dateiebene trackt, basiert die Versionskontrolle von Git auf Snapshots. So besteht ein SVN-Commit beispielsweise aus einem Unterschied im Vergleich zur Originaldatei, die dem Repository hinzugefügt wurde. Git dagegen hält die gesamten Inhalte aller Dateien in jedem Commit fest.

Dadurch sind viele Git-Operationen deutlich schneller als bei SVN, da eine bestimmte Version einer Datei nicht erst aus den Diffs zusammenberechnet werden muss. Die komplette Revision einer jeden Datei ist direkt in der internen Git-Datenbank verfügbar.

Das Snapshot-Modell von Git hat weitreichende Auswirkungen auf nahezu alle Aspekte des Versionskontrollmodells, von den Branching- und Merging-Werkzeugen bis hin zu den Kollaborations-Workflows.

Beispiel

Das folgende Beispiel geht davon aus, dass in einer Datei namens hallo.py etwas verändert wurde und dass diese Datei nun bereit fürs Committen in die Projekt-Historie ist. Zunächst muss der Entwickler die Datei mit git add in den Staging-Bereich stagen, dann kann er den Snapshot committen:

git add hallo.py
git commit

Dann öffnet sich ein Text-Editor, der via git config definiert werden kann. Dieser zeigt Infos darüber an, was committet wird, und fragt nach der Commit-Nachricht:

# 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 <file>..." to unstage)
#
# modified: hallo.py

Git verlangt keine Commit-Nachrichten, die bestimmten Formatierungsvorgaben unterliegen, aber es hat sich eingebürgert, dass Entwickler in der ersten Zeile den gesamten Commit in weniger als 50 Zeichen zusammenfassen, eine Zeile freilassen und dann detailliert erläutern, was geändert wurde. Ein Beispiel:

Änderung der Nachricht, die hallo.py anzeigt

- Update der sayHello() Funktion, um Nutzernamen auszugeben
- Ändern der sayGoodbye() Funktion für nettere Nachricht

Im nächsten Git-Tutorial werden wir uns dann mit dem Inspizieren von Git-Repos befassen.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash, Atlassians Git-Repository-Managementsystem? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten