Bei der Arbeit in Git oder anderen Versionskontrollsystemen ist das Konzept des "Speicherns" deutlich nuancierter als das Speichern in einem Textverarbeitungsprogramm oder anderen herkömmlichen Anwendungen zur Dateibearbeitung. Der traditionelle Softwareausdruck "Speichern" ist ein Synonym für den Git-Begriff "Committen". Ein Commit ist das Git-Äquivalent einer "Speicherung". Das herkömmliche Speichern kann als ein Dateisystemvorgang betrachtet werden, der eine vorhandene Datei überschreibt oder eine neue Datei schreibt. Der Vorgang eines Git-Commits umfasst eine Sammlung von Dateien und Verzeichnissen.

Das Speichern von Änderungen in Git ist ebenfalls anders in SVN. SVN-Commits oder "Check-ins" sind Abläufe, bei denen ein Remote-Push an einen zentralisierten Server durchgeführt wird. Dies bedeutet, dass bei SVN-Commits für das vollständige Speichern von Änderungen am Projekt eine Internetverbindung erforderlich ist. Git-Commits können dagegen lokal erfasst und aufgebaut werden und anschließend kann mit dem Befehl git push -u origin master nach Bedarf ein Push an den Remote-Server durchgeführt werden. Diese beiden Methode unterscheiden sich fundamental in ihrer Architektur und ihrem Design. Git ist ein verteiltes Anwendungsmodell, während es sich bei SVN um ein zentralisiertes Modell handelt. Verteilte Anwendungen sind im Allgemeinen zuverlässiger, da sie nicht über einen Single Point of Failure verfügen, wie dies bei einem zentralisierten Server der Fall ist.

Die Befehle git add, git status, and git commit werden alle in Kombination verwendet, um einen Snapshot des aktuellen Zustands eines Git-Projekts zu speichern.

Git verfügt über einen zusätzlichen Speichermechanismus namens "Stash". Der Stash ist ein vorübergehender Speicherbereich für Änderungen, die noch nicht für einen Commit bereit sind. Der Stash wird im Arbeitsverzeichnis, dem ersten der drei Bäume, betrieben und kann auf vielfache Weise genutzt werden. Weitere Informationen erhältst du auf der git stash-Seite.

Ein Git-Repository kann so konfiguriert werden, dass bestimmte Dateien oder Verzeichnisse ignoriert werden. Dadurch wird verhindert, dass Git Änderungen an ignorierten Inhalten speichert. Git verfügt über mehrere Konfigurationsmethoden, die die Ignorieren-Liste verwalten. Git ignore configure wird auf der git ignore-Seite ausführlicher behandelt.

git add

Mit dem Befehl git add fügst du eine Änderung aus dem Arbeitsverzeichnis zur Staging-Umgebung hinzu. Git wird damit angewiesen, Aktualisierungen einer bestimmten Datei in den nächsten Commit aufzunehmen. Allerdings hat git add keine signifikanten Auswirkungen auf das Repository: Änderungen werden erst eingetragen, wenn du git commit ausführst.

Neben diesen beiden Befehlen musst du auch git status ausführen, um den Status des Arbeitsverzeichnisses und der Staging-Umgebung abzurufen.

Wie es funktioniert

Die Befehle git add und git commit bilden den grundlegenden Git-Workflow. Ganz gleich, welches Zusammenarbeitsmodell dein Team nutzt: Wenn du mit Git arbeiten möchtest, musst du die Funktionsweise dieser beiden Befehle verstehen. Sie machen es möglich, verschiedene Versionen eines Projekts im Repository-Verlauf aufzuzeichnen.

Die Projektentwicklung fußt auf dem grundlegenden Muster "Bearbeitung/Staging/Commit". Zunächst bearbeitest du deine Dateien in deinem Arbeitsverzeichnis. Sobald du bereit bist, eine Kopie des aktuellen Projektstatus zu speichern, überführst du deine Änderungen mit git add in die Staging-Umgebung. Bist du mit dem Snapshot in der Staging-Umgebung schließlich zufrieden, committest du ihn mit git commit in den Projektverlauf. Mit dem Befehl git reset kannst du einen Commit oder einen gestagten Snapshot rückgängig machen.

Neben git add und git commit ist ein dritter Befehl – git push– grundlegend für einen vollständigen kollaborativen Git-Workflow. git push wird verwendet, um die committeten Änderungen zur Zusammenarbeit an Remote-Repositorys zu senden. Dies ermöglicht es anderen Teammitgliedern, auf eine Reihe gespeicherter Änderungen zuzugreifen.

Git Tutorial: git add Snapshot

Der Befehl git add darf nicht mit dem Befehl svn add verwechselt werden, über den du deinem Repository Dateien hinzufügen kannst. git add arbeitet auf einer abstrakteren Ebene, nämlich der Ebene der Änderungen. Das bedeutet konkret: git add muss bei jeder Dateiänderung aufgerufen werden, svn add hingegen pro Datei nur ein einziges Mal. Auch wenn dieser Workflow redundant erscheinen mag, so macht er die Projektorganisation doch um ein Vielfaches einfacher.

Staging-Umgebung

Die Hauptfunktion des Befehls git add ist die Übertragung von ausstehenden Änderungen vom Arbeitsverzeichnis in den Staging-Bereich. Die Staging-Umgebung ist eines der besonderen Features von Git. Wenn du es gewohnt bist, mit SVN (oder gar Mercurial) zu arbeiten, brauchst du womöglich eine gewisse Zeit, um dich auf eine Staging-Umgebung einzustellen. Vielleicht hilft es dir, wenn du sie dir als Puffer zwischen dem Arbeitsverzeichnis und dem Projektverlauf vorstellst. Der Staging-Bereich ist zusammen mit dem Arbeitsverzeichnis und dem Commitverlauf einer der "drei Bäume" von Git.

Statt alle Änderungen zu bestätigen, die du seit dem letzten Commit gemacht hast, ermöglicht es dir der Staging-Bereich, zusammengehörige Änderungen in stark fokussierten Snapshots zu gruppieren, bevor du sie für den Projektverlauf bestätigst. Das heißt, dass du alle möglichen Änderungen an nicht zusammengehörigen Dateien vornehmen, dann zurückgehen und sie in logische Commits unterteilen kannst, indem du zusammengehörige Änderungen dem Staging-Bereich hinzufügst und diese nacheinander bestätigst. Wie in jedem Revisionskontrollsystem ist es wichtig, auch kleinste Commits zu erstellen, damit bei minimalen Auswirkungen auf andere Teile des Projekts Bugs nachvollzogen und Änderungen rückgängig gemacht werden können.

Allgemeine Optionen

git add <file>

Mit diesem Befehl überführst du alle Änderungen in <file> in die Staging-Umgebung, damit sie in den nächsten Commit aufgenommen werden können.

git add <directory>

Mit diesem Befehl überführst du alle Änderungen in <directory> in die Staging-Umgebung, damit sie in den nächsten Commit aufgenommen werden können.

git add -p

Mit diesem Befehl startest du eine interaktive Staging-Sitzung, in der du auswählen kannst, welche Abschnitte einer Datei in den nächsten Commit aufgenommen werden sollen. Dir wird ein Block von Änderungen angezeigt und du wirst zur Eingabe eines Befehls aufgefordert. Mit y verschiebst du den Block in die Staging-Umgebung, mit n ignorierst du den Block. Mit der Option s teilst du den Block in kleinere Blöcke auf, mit e kannst du ihn manuell bearbeiten und mit q brichst du den Vorgang ab.

Beispiele

Wenn du ein neues Projekt beginnst, hat git add dieselbe Funktion wie svn import. Mithilfe der folgenden beiden Befehle kannst du einen ersten Commit des aktuellen Verzeichnisses erstellen:

git add .
git commit

Sobald du dein Projekt eingerichtet hast, kannst du neue Dateien hinzufügen, indem du den entsprechenden Pfad an git add übergibst:

git add hello.py
git commit

Die obigen Befehle können auch zum Erfassen von Änderungen an bestehenden Dateien genutzt werden. Beachte, dass Git nicht zwischen Staging-Änderungen in neuen Dateien und Änderungen in Dateien, die dem Repository bereits hinzugefügt wurden, unterscheidet.

Zusammenfassung

Während des Review-Prozesses ist git add der erste Befehl einer Kette von Vorgängen, die Git anweisen, einen Snapshot des aktuellen Projektzustands im Commit-Verlauf zu "speichern". Alleinstehend verwendet befördert git add ausstehende Änderungen vom Arbeitsverzeichnis in den Staging-Bereich. Der Befehl git status wird zur Untersuchung des aktuellen Zustands des Repositorys verwendet und kann zur Bestätigung einer git add-Übertragung herangezogen werden. Mit dem Befehl git reset wird ein git add rückgängig gemacht. Anschließend wird mit git commit ein Snapshot des Staging-Verzeichnisses an den Repository-Commit-Verlauf committet.

Möchtest du Git kennenlernen?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen