git add
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 verläuft ebenfalls anders als in SVN. SVN-Commits oder "Check-ins" sind Vorgänge, bei denen ein Remote-Push an einen zentralisierten Server durchgeführt wird. Dies bedeutet, dass bei SVN-Commits für das ordnungsgemäße "Speichern" von Änderungen am Projekt eine Internetverbindung erforderlich ist. Git-Commits können dagegen lokal erfasst und aufgebaut und anschließend bei Bedarf mit dem Befehl git push -u origin main
an den Remote-Server gepusht werden. Diese beiden Methoden unterscheiden sich grundsätzlich in ihrer Architektur. 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 und git commit werden alle in Kombination verwendet, um einen Snapshot des aktuellen Status 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, verwendet 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
Der Befehl git add
fügt eine Änderung im Arbeitsverzeichnis zum Staging-Bereich 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 aufgezeichnet, 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 funktioniert "git revert"?
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 im 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 gestagten Snapshot 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 an Remote-Repositorys zu senden und sie gemeinsam zu bearbeiten. Dies ermöglicht es anderen Teammitgliedern, auf eine Reihe gespeicherter Änderungen zuzugreifen.
Zugehöriges Material
git branch
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
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 der abstrakteren 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, macht er die Projektorganisation doch um ein Vielfaches einfacher.
Staging-Umgebung
Die Hauptfunktion des Befehls git add
ist die Übertragung von ausstehenden Änderungen im Arbeitsverzeichnis an den Staging
-Bereich. Der Staging-Bereich 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 einen Staging-Bereich einzustellen. Vielleicht hilft es, wenn du ihn dir als Puffer zwischen dem Arbeitsverzeichnis und dem Projektverlauf vorstellst. Der Staging-Bereich ist zusammen mit dem Arbeitsverzeichnis und dem Commit-Verlauf 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 den Staging-Bereich, 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 den Staging-Bereich, 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
Zusammenfassend können wir festhalten, dass git add
der erste Befehl in einer Reihe von Vorgängen ist, die Git anweisen, einen Snapshot des aktuellen Projektstatus im Commit-Verlauf zu "speichern". Allein verwendet überträgt git add
ausstehende Änderungen vom Arbeitsverzeichnis in den Staging-Bereich. Der Befehl git status wird zur Untersuchung des aktuellen Repository-Status verwendet und kann zur Bestätigung einer git add
-Übertragung herangezogen werden. Mit dem Befehl git reset wird git add
rückgängig gemacht. Anschließend wird mit git commit ein Snapshot des Staging-Verzeichnisses an den Repository-Commit-Verlauf committet.
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.