Git commit
Mit dem Befehl git commit erfasst du einen Snapshot der aktuell bereitgestellten Änderungen 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 die zwei Git-Befehle, die am häufigsten genutzt werden.
"git commit" im Vergleich mit "svn commit"
Die Befehle git commit und svn commit haben zwar denselben Namen, 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 funktioniert "git revert"?
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 Status 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 hingegen selbst, wann du mit dem zentralen Repository interagieren möchtest. Genauso wie der Staging-Bereich als Puffer zwischen dem Arbeitsverzeichnis und dem Projektverlauf fungiert, dient das lokale Repository von Entwicklern als Puffer zwischen ihren Beiträgen und dem zentralen Repository.
Somit ist das Entwicklungsmodell für Git-Benutzer ein anderes. Statt eine Änderung vorzunehmen und diese direkt in das zentrale Repository zu committen, haben Git-Entwickler 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 Zeitpunkt 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äufiger kleinere Integrationen 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.
Zugehöriges Material
git branch
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
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-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 commitMit 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 -aMit 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 Verknüpfungsbefehl für Hauptbenutzer, bei dem die Optionen -a und -m miteinander kombiniert werden. So wird sofort ein Commit aller bereitgestellten Änderungen erstellt und eine Inline-Commit-Nachricht verfasst.
git commit --amendMit 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 den Staging-Bereich verschieben. Anschließend kannst du den Snapshot aus dem Staging-Bereich committen.
git add hello.pyMit diesem Befehl wird hello.py in den Staging-Bereich von Git aufgenommen. Um uns das Ergebnis dieser Aktion anzusehen, verwenden wir den Befehl git status.
git status
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.pyDie in grün angezeigte Ausgabe "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 commitEin Texteditor wird geöffnet (anpassbar über git config). Du wirst aufgefordert, eine Commit-Protokollnachricht einzugeben, und siehst eine detaillierte Liste der Commits:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch main
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
#modified: hello.pyFü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 --amendAuch 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 bereitgestellt werden sollen. Dann erstellst du mit git commit einen Snapshot der bereitgestellten Änderungen 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 Status des Staging-Bereichs 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.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
