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 in diesem und im nachfolgenden Beitrag, wie Änderungen vorgenommen und gespeichert werden. Zunächst zum Befehl git add.
git add
Der Befehl git add fügt eine Änderung im Arbeitsverzeichnis dem Staging-Bereich hinzu. Er sagt Git beispielsweise, dass der nächste Commit Aktualisierungen an einer bestimmten Datei enthalten soll. Allerdings berührt git add das Repository gar nicht wirklich – Änderungen werden nicht festgehalten, ehe nicht git commit ausgeführt wird.
Zusätzlich zu diesen Befehlen wird das Kommando git status benötigt, um den Status des Arbeitsverzeichnisses und des Staging-Bereichs einzusehen.
Nutzung
git add <datei>
Alle Änderungen in der <datei> für den nächsten Commit stagen.
git add <verzeichnis>
Alle Änderungen im <verzeichnis> für den nächsten Commit stagen.
git add -p
Beginnt eine interaktive Staging-Session, in deren Rahmen der Entwickler Teile einer Datei wählen kann, die dem nächsten Commit hinzugefügt werden sollen. Dem Entwickler wird ein Chunk an Änderungen präsentiert, und Git erwartet eine Eingabe:
y, um den Chunk zu stagen.n, um den Chunk zu ignorieren.s, um den Chunk in kleinere Chunks aufzuteilen.e, um den Chunk manuell zu editieren.q, um zu beenden.
Hinweise
Die Befehle git add und git commit bilden den grundlegenden Git-Workflow. Sie muss jeder Git-Nutzer verstehen, unabhängig vom Kollaborationsmodell des Teams. Diese Kommandos sind dazu da, Versionen eines Projekts in der Historie des Repositorys festzuhalten.
Die Entwicklung eines Projekts dreht sich um das Edit/Stage/Commit-Muster. Zunächst werden Dateien im Arbeitsverzeichnis editiert. Ist der Entwickler bereit, eine Kopie des aktuellen Projektstatus zu speichern, nutzt er git add, um die Änderungen zu stagen. Ist er damit zufrieden, committet er mit git commit in die Projekt-Historie.
Der Befehl git add ist nicht mit dem Befehl svn add zu verwechseln, der dem Repository eine Datei hinzufügt. git add funktioniert stattdessen auf einer eher abstrakten Ebene im Hinblick auf Änderungen. Das bedeutet, dass git add jedes Mal aufgerufen werden muss, wenn man eine Datei ändert, während svn add nur ein Mal für jede Datei aufgerufen wird. Das mag redundant klingen, aber der Workflow macht es viel einfacher, ein Projekt zu organisieren.
Der Staging-Bereich
Der Staging-Bereich gehört zu den Eigenheiten von Git, und es kann etwas dauern, bis man dieses Feature richtig verstanden hat, wenn man einen SVN- oder auch einen Mercurial-Hintergrund hat. Am besten betrachtet man ihn als Puffer zwischen Arbeitsverzeichnis und Projekt-Historie.
Statt alle Änderungen zu committen, die seit dem letzten Commit vorgenommen wurden, bietet der Staging-Bereich die Möglichkeit, zusammengehörende Änderungen in fokussierte Snapshots zu gruppieren, bevor sie tatsächlich in die Projekt-Historie committet werden.
Der Entwickler kann alle möglichen Änderungen an nicht zusammengehörenden Dateien vornehmen und dann zurückgehen, um sie in logische Commits aufzusplitten, indem er dem Staging-Bereich zusammengehörende Änderungen hinzufügt, und diese Stück für Stück zu committen. Wie in jedem Revisionskontrollsystem ist es wichtig, mit kleinstmöglichen Commits zu arbeiten; so ist es einfach, Bugs zurückzuverfolgen und Änderungen ohne größere Auswirkungen auf das gesamte Projekt zurückzunehmen.
Beispiel
Zu Beginn eines neuen Projekts erfüllt git add dieselbe Funktion wie svn import. Um einen initialen Commit des aktuellen Verzeichnisses zu erzeugen, sind die folgenden beiden Befehle nötig:
git add .
git commit
Wenn das Projekt bereits läuft, können neue Dateien wie folgt hinzugefügt werden:
git add hallo.py
git commit
Die Befehle oben können auch genutzt werden, um Änderungen an bestehenden Dateien festzuhalten. Nochmals: Git unterscheidet nicht zwischen Staging-Änderungen in neuen Dateien und Änderungen in Dateien, die bereits dem Repository hinzugefügt wurden.
Der nächste Teil des Tutorials widmet sich dann dem oben schon angesprochenen Befehl git commit.
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
