4Was sind Commits?
Der wichtigste Begriff in Git ist das Commit. Git verwaltet Versionen von Software, und jede Version wird als Commit in einem Repository abgelegt. Ein Commit umfasst dabei immer das ganze Projekt. Mit einem Commit wird für jede von Git verwaltete Datei im Projekt eine Kopie im Repository gespeichert.
Abbildung 4–1 zeigt eine Zusammenfassung1 wichtiger Informationen zu einem Commit.
commit 9acc5d5efec1d2d62f7e98bcc3880cda762cb831
Date: Sat Dec 18 18:20:45 2010 +0100
Abschnitt darüber, was Commits sind.
buch/commits/commits.tex | 28 +++++++++++++++++++++++++---
1 files changed, 25 insertions(+), 3 deletions(-)
Abb. 4–1 Informationen zu einem Commit
Als Erstes sieht man den sogenannten Commit-Hash 9acc5d5e...cb831. Dann folgen Informationen zu Autor und Commit-Zeitpunkt und ein Kommentar. Abschließend zeigt eine Zusammenfassung, welche Dateien sich gegenüber der vorigen Version verändert haben. Was die Zusammenfassung nicht zeigt: Auch dieses Commit enthält nicht nur die geänderte Datei commits.tex, sondern alle Dateien des Projekts. Für jedes Commit berechnet Git einen 40 Zeichen langen eindeutigen Code, den sogenannten Commit-Hash. Kennt man diesen Commit-Hash, kann man die Dateien des Projekts aus dem Repository so wiederherstellen, wie sie zum Zeitpunkt des Commits festgehalten wurden. Das Wiederherstellen einer Version bezeichnet man in Git als Checkout.
4.1Zugriffsberechtigungen und Zeitstempel
Git speichert die Zugriffsberechtigungen (POSIX File Permissions: Read, Write, Execute) für jede Datei, nicht aber den Änderungszeitstempel. Beim Checkout wird der Änderungszeitstempel auf die aktuelle Uhrzeit gesetzt.
Warum werden Änderungszeitstempel nicht gespeichert?
Anmerkung: Der Grund dafür ist, dass viele Build-Tools den Änderungszeitstempel als Auslöser für das erneute Bauen von Dateien nutzen: Ist die letzte Änderung jünger als das letzte Build-Ergebnis, muss neu gebaut werden. Da Git beim Checkout den Änderungszeitstempel immer auf die aktuelle Zeit setzt, lösen auch Wechsel auf ältere Versionen den Build-Vorgang korrekt aus.
4.2Die Befehle add und commit
Mit .gitignore Dateien unversioniert lassen → Seite 50
Mit den beiden Befehlen add und commit erstellt man Commits.
Schritt für Schritt
Alle Änderungen in einem Commit übernehmen
Erstelle ein Commit mit allen aktuellen Änderungen im Workspace. Dies umfasst neu hinzugekommene Dateien und Löschungen. Ausgenommen sind nur jene Dateien, die in .gitignore eingetragen sind (siehe auch »Mit .gitignore Dateien unversioniert lassen« ab Seite 50).
1. Änderungen anmelden
Mit dem add-Befehl werden Änderungen für das nächste Commit angemeldet. Die Option --all erfasst alle Änderungen im ganzen Workspace, egal ob geändert, hinzugefügt oder gelöscht wurde.
Es kann auch die Kurzform git add -A verwendet werden.
2. Commit erstellen
Das neue Commit wird erstellt.
4.3Exkurs: Mehr über Commit-Hashes
Auf den ersten Blick wirken die 40 Zeichen langen Commit-Hashes etwas sperrig. Andere Versionsverwaltungen verwenden einfach fortlaufende Nummern (Subversion2) oder Versionsnamen wie »1.17« (CVS3). Es gibt jedoch gute Gründe, weshalb sich die Entwickler von Git für Hashes entschieden haben:
4.3.1Commit-Hashes können lokal erzeugt werden
Für eine fortlaufende Nummerierung müssten sich die Instanzen von Git koordinieren und Informationen über getätigte Commits austauschen.
Die Commit-Hashes werden aus dem Inhalt der Dateien und den Metadaten (Autor, Commit-Zeitpunkt) errechnet. Für die Berechnung ist eine Kommunikation mit anderen Rechnern oder zentralen Servern nicht erforderlich. Ein neues Commit kann man also jederzeit und überall erstellen.
Die Wahrscheinlichkeit, dass zwei verschiedene Änderungen zufällig denselben Commit-Hash bekommen, ist extrem gering. Immerhin stehen 2160 verschiedene Werte zur Verfügung.
4.3.2Commit-Hashes sind Prüfsummen
Noch wichtiger ist jedoch Folgendes: Commit-Hashes sind mehr als nur Namen für festgehaltene Softwarestände. Sie sind glei...