2.2 Git Grundlagen - Änderungen nachverfolgen und im Repository speichern

Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich Ihre Dateien gerade befinden, ist der Befehl git status. Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern:

Dieser Zustand wird auch als sauberes Arbeitsverzeichnis (engl. clean working directory) bezeichnet. Mit anderen Worten, es gibt keine Dateien, die unter Versionsverwaltung stehen und seit dem letzten Commit geändert wurden – andernfalls würden sie hier aufgelistet werden. Außerdem teilt Ihnen der Befehl mit, auf welchem Branch Sie gerade arbeiten und informiert Sie darüber, dass dieser sich im Vergleich zum Branch auf dem Server nicht verändert hat. Momentan ist dieser Zweig immer master, was der Vorgabe entspricht; Sie müssen sich jetzt nicht darum kümmern. Wir werden im Kapitel Git Branching auf Branches detailliert eingehen.

Nehmen wir einmal an, Sie fügen eine neue Datei mit dem Namen README zu Ihrem Projekt hinzu. Wenn die Datei zuvor nicht existiert hat und Sie jetzt git status ausführen, zeigt Git die bisher nicht versionierte Datei wie folgt an:

Alle Dateien, die im Abschnitt „Untracked files“ aufgelistet werden, sind Dateien, die bisher noch nicht versioniert sind. Dort wird jetzt auch die Datei README angezeigt. Mit anderen Worten, die Datei README wird in diesem Bereich gelistet, weil sie im letzten Schnappschuss nicht enthalten war und noch nicht gestaged wurde. Git nimmt eine solche Datei nicht automatisch in die Versionsverwaltung auf, sondern Sie müssen Git dazu ausdrücklich auffordern. Ansonsten würden generierte Binärdateien oder andere Dateien, die Sie nicht in Ihrem Repository haben möchten, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei README verfolgen und fügen sie deshalb zur Versionsverwaltung hinzu.

Um eine neue Datei zu versionieren, können Sie den Befehl git add verwenden. Für Ihre neue README Datei, können Sie folgendes ausführen:

Wenn Sie erneut den Befehl git status ausführen, werden Sie sehen, dass sich Ihre README Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist:

Sie können erkennen, dass die Datei für den nächsten Commit vorgemerkt ist, weil sie unter der Rubrik „Changes to be committed“ aufgelistet ist. Wenn Sie jetzt einen Commit anlegen, wird der Schnappschuss den Zustand der Datei festhalten, den sie zum Zeitpunkt des Befehls git add hat. Sie erinnern sich vielleicht daran, wie Sie vorhin git init und anschließend git add <files> ausgeführt haben. Mit diesen Befehlen haben Sie die Dateien in Ihrem Verzeichnis zur Versionsverwaltung hinzugefügt. Der Befehl git add akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn Sie ein Verzeichnis angeben, fügt git add alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu.

Lassen Sie uns jetzt eine bereits versionierte Datei ändern. Wenn Sie zum Beispiel eine bereits unter Versionsverwaltung stehende Datei mit dem Dateinamen CONTRIBUTING.md ändern und danach den Befehl git status erneut ausführen, erhalten Sie in etwa folgende Ausgabe:

Die Datei CONTRIBUTING.md erscheint im Abschnitt „Changes not staged for commit“. Das bedeutet, dass eine versionierte Datei im Arbeitsverzeichnis verändert worden ist, aber noch nicht für den Commit vorgemerkt wurde. Um sie vorzumerken, führen Sie den Befehl git add aus. Der Befehl git add wird zu vielen verschiedenen Zwecken eingesetzt. Man verwendet ihn, um neue Dateien zur Versionsverwaltung hinzuzufügen, Dateien für einen Commit vorzumerken und verschiedene andere Dinge – beispielsweise einen Konflikt aus einem Merge als aufgelöst zu kennzeichnen. Leider wird der Befehl git add oft missverstanden. Viele assoziieren damit, dass damit Dateien zum Projekt hinzugefügt werden. Wie Sie aber gerade gelernt haben, wird der Befehl auch noch für viele andere Dinge eingesetzt. Wenn Sie den Befehl git add einsetzen, sollten Sie das eher so sehen, dass Sie damit einen bestimmten Inhalt für den nächsten Commit vormerken. Lassen Sie uns nun mit git add die Datei CONTRIBUTING.md zur Staging-Area hinzufügen und danach das Ergebnis mit git status kontrollieren:

Beide Dateien sind nun für den nächsten Commit vorgemerkt. Nehmen wir an, Sie wollen jetzt aber noch eine weitere Änderung an der Datei CONTRIBUTING.md vornehmen, bevor Sie den Commit tatsächlich starten. Sie öffnen die Datei erneut, ändern sie entsprechend ab und eigentlich wären Sie ja jetzt bereit den Commit durchzuführen. Allerdings lassen Sie uns vorher noch einmal den Befehl git status ausführen:

Was zum Kuckuck …​? Jetzt wird die Datei CONTRIBUTING.md sowohl in der Staging-Area als auch als geändert aufgelistet. Wie ist das möglich? Die Erklärung dafür ist, dass Git eine Datei in exakt dem Zustand für den Commit vormerkt, in dem sie sich befindet, wenn Sie den Befehl git add ausführen. Wenn Sie den Commit jetzt anlegen, wird die Version der Datei CONTRIBUTING.md denjenigen Inhalt haben, den sie hatte, als Sie git add zuletzt ausgeführt haben und nicht denjenigen, den sie in dem Moment hat, wenn Sie den Befehl git commit ausführen. Wenn Sie stattdessen die gegenwärtige Version im Commit haben möchten, müssen Sie erneut git add ausführen, um die Datei der Staging-Area hinzuzufügen:

Die Ausgabe von git status ist sehr umfassend und auch ziemlich wortreich. Git hat auch ein Kurzformat, mit dem Sie Ihre Änderungen kompakter sehen können. Wenn Sie git status -s oder git status --short ausführen, erhalten Sie eine kürzere Darstellung des Befehls:

Neue Dateien, die nicht versioniert werden, haben ?? neben sich, neue Dateien, die der Staging-Area hinzugefügt wurden, haben ein A, geänderte Dateien haben ein M usw. Es gibt zwei Spalten für die Ausgabe – die linke Spalte zeigt den Status der Staging-Area und die rechte Spalte den Status des Verzeichnisbaums. So ist beispielsweise in der Bildschirmausgabe oben die Datei README im Arbeitsverzeichnis geändert, aber noch nicht staged, während die Datei lib/simplegit.rb geändert und staged ist. Das Rakefile wurde modifiziert, staged und dann wieder modifiziert, so dass es Änderungen an ihm gibt, die sowohl staged als auch unstaged sind.

Häufig gibt es eine Reihe von Dateien, die Git nicht automatisch hinzufügen oder schon gar nicht als „nicht versioniert“ (eng. untracked) anzeigen soll. Dazu gehören in der Regel automatisch generierte Dateien, wie Log-Dateien oder Dateien, die von Ihrem Build-System erzeugt werden. In solchen Fällen können Sie die Datei .gitignore erstellen, die eine Liste mit Vergleichsmustern enthält. Hier ist eine .gitignore Beispieldatei:

Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf „.o“ oder „.a“ enden – Objekt- und Archivdateien, die das Ergebnis der Codegenerierung sein könnten. Die zweite Zeile weist Git an, alle Dateien zu ignorieren, deren Name mit einer Tilde (~) enden, was von vielen Texteditoren wie Emacs zum Markieren temporärer Dateien verwendet wird. Sie können auch ein Verzeichnis „log“, „tmp“ oder „pid“ hinzufügen, eine automatisch generierte Dokumentation usw. Es ist im Allgemeinen eine gute Idee, die .gitignore Datei für Ihr neues Repository einzurichten, noch bevor Sie loslegen. So können Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten.

Die Richtlinien für Vergleichsmuster, die Sie in der Datei .gitignore eingeben können, lauten wie folgt:

Platzhalter-Zeichen sind wie einfache, reguläre Ausdrücke, die von der Shell genutzt werden. Ein Sternchen (*) entspricht null oder mehr Zeichen; [abc] entspricht jedem Zeichen innerhalb der eckigen Klammern (in diesem Fall a, b oder c); ein Fragezeichen (?) entspricht einem einzelnen Zeichen und eckige Klammern, die durch einen Bindestrich ([0-9]) getrennte Zeichen einschließen, passen zu jedem Zeichen dazwischen (in diesem Fall von 0 bis 9). Sie können auch zwei Sterne verwenden, um verschachtelte Verzeichnisse abzugleichen; a/**/z würde zu a/z, a/b/z, a/b/c/z usw. passen.

Hier ist eine weitere .gitignore Beispieldatei:

Wenn der Befehl git status für Sie zu vage ist – Sie wollen genau wissen, was Sie geändert haben, nicht nur welche Dateien geändert wurden – können Sie den Befehl git diff verwenden. Wir werden git diff später ausführlicher behandeln, aber Sie werden es wahrscheinlich am häufigsten verwenden, um diese beiden Fragen zu beantworten: Was hat sich geändert, ist aber noch nicht zum Commit vorgemerkt (engl. staged)? Und was haben Sie zum Commit vorgemerkt und können es demnächst committen? Der Befehl git status beantwortet diese Fragen ganz allgemein, indem er die Dateinamen auflistet; git diff zeigt Ihnen aber genau die hinzugefügten und entfernten Zeilen – sozusagen den Patch.

Nehmen wir an, Sie bearbeiten und merken die Datei README zum Commit vor (engl. stage) und bearbeiten dann die Datei CONTRIBUTING.md, ohne sie zu „stagen“. Wenn Sie den Befehl git status ausführen, sehen Sie erneut so etwas wie das hier:

Um die Änderungen zu sehen, die Sie noch nicht zum Commit vorgemerkt haben, geben Sie den Befehl git diff, ohne weitere Argumente, ein:

Dieses Kommando vergleicht, was sich in Ihrem Arbeitsverzeichnis befindet, mit dem, was sich in Ihrer Staging-Area befindet. Das Ergebnis gibt Ihnen an, welche Änderungen Sie vorgenommen haben, die noch nicht „gestaged“ sind.

Wenn Sie wissen wollen, was Sie zum Commit vorgemerkt haben, das in Ihren nächsten Commit einfließt, können Sie git diff --staged verwenden. Dieser Befehl vergleicht Ihre zum Commit vorgemerkten Änderungen mit Ihrem letzten Commit:

Es ist wichtig zu wissen, dass git diff von sich aus nicht alle Änderungen seit Ihrem letzten Commit anzeigt – nur die Änderungen, die noch „unstaged“ sind. Wenn Sie alle Ihre Änderungen bereits „gestaged“ haben, wird git diff Ihnen keine Antwort geben.

Ein weiteres Beispiel: wenn Sie die Datei CONTRIBUTING.md zum Commit vormerken und dann wieder bearbeiten, können Sie mit git diff die Änderungen in der „staged“-Datei und die „unstaged“-Änderungen sehen. Wenn Sie folgendes gemacht haben

können Sie jetzt mit git diff sehen, was noch nicht zum Commit vorgemerkt ist

und git diff --cached zeigt Ihnen, was Sie bisher zum Commit vorgemerkt haben (--staged und --cached sind Synonyme, sie bewirken das Gleiche):

Nachdem Ihre Staging-Area nun so eingerichtet ist, wie Sie es wünschen, können Sie Ihre Änderungen committen. Denken Sie daran, dass alles, was noch nicht zum Commit vorgemerkt ist – alle Dateien, die Sie erstellt oder geändert haben und für die Sie seit Ihrer Bearbeitung nicht mehr git add ausgeführt haben – nicht in diesen Commit einfließen werden. Sie bleiben aber als geänderte Dateien auf Ihrer Festplatte erhalten. In diesem Beispiel nehmen wir an, dass Sie beim letzten Mal, als Sie git status ausgeführt haben, gesehen haben, dass alles zum Commit vorgemerkt wurde und bereit sind, Ihre Änderungen zu committen. Am einfachsten ist es, wenn Sie git commit eingeben:

Dadurch wird der Editor Ihrer Wahl gestartet.

Der Editor zeigt den folgenden Text an (dieses Beispiel ist eine Vim-Ansicht):

Sie können erkennen, dass die Standard-Commit-Meldung die neueste Ausgabe des auskommentierten Befehls git status und eine leere Zeile darüber enthält. Sie können diese Kommentare entfernen und Ihre Commit-Nachricht eingeben oder Sie können sie dort stehen lassen, damit Sie sich merken können, was Sie committen.

Wenn Sie den Editor verlassen, erstellt Git Ihren Commit mit dieser Commit-Nachricht (mit den Kommentaren und ausgeblendetem Diff).

Alternativ können Sie Ihre Commit-Nachricht auch inline mit dem Befehl commit -m eingeben. Das Flag -m ermöglicht die direkte Eingabe eines Kommentartextes:

Jetzt haben Sie Ihren ersten Commit erstellt! Sie können sehen, dass der Commit eine Nachricht über sich selbst ausgegeben hat: in welchen Branch Sie committet haben (master), welche SHA-1-Prüfsumme der Commit hat (463dc4f), wie viele Dateien geändert wurden und Statistiken über hinzugefügte und entfernte Zeilen im Commit.

Denken Sie daran, dass der Commit den Snapshot aufzeichnet, den Sie in Ihrer Staging-Area eingerichtet haben. Alles, was von Ihnen nicht zum Commit vorgemerkt wurde, liegt immer noch als modifiziert da. Sie können einen weiteren Commit durchführen, um es zu Ihrer Historie hinzuzufügen. Jedes Mal, wenn Sie einen Commit ausführen, zeichnen Sie einen Schnappschuss Ihres Projekts auf, auf den Sie zurückgreifen oder mit einem späteren Zeitpunkt vergleichen können.

Obwohl es außerordentlich nützlich sein kann, Commits so zu erstellen, wie Sie es wünschen, ist die Staging-Area manchmal etwas komplexer, als Sie es für Ihren Workflow benötigen. Wenn Sie die Staging-Area überspringen möchten, bietet Git eine einfache Kurzform. Durch das Hinzufügen der Option -a zum Befehl git commit wird jede Datei, die bereits vor dem Commit versioniert war, automatisch von Git zum Commit vorgemerkt (engl. staged), so dass Sie den Teil git add überspringen können:

Beachten Sie, dass Sie in diesem Fall git add nicht für die Datei CONTRIBUTING.md ausführen müssen, bevor Sie committen. Das liegt daran, dass das -a-Flag alle geänderten Dateien einschließt. Das ist bequem, aber seien Sie vorsichtig. Manchmal führt dieses Flag dazu, dass Sie ungewollte Änderungen vornehmen.

Um eine Datei aus Git zu entfernen, müssen Sie sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen. Der Befehl git rm erledigt das und entfernt die Datei auch aus Ihrem Arbeitsverzeichnis, so dass Sie sie beim nächsten Mal nicht mehr als „untracked“-Datei sehen.

Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem „Changes not staged for commit“-Bereich (das ist die unstaged-Area) Ihrer git status Ausgabe:

Wenn Sie dann git rm ausführen, wird die Entfernung der Datei zum Commit vorgemerkt:

Wenn Sie das nächste Mal einen Commit ausführen, ist die Datei weg und ist nicht mehr versioniert (engl. tracked). Wenn Sie die Datei geändert oder bereits zur Staging-Area hinzugefügt haben, müssen Sie das Entfernen mit der Option -f erzwingen. Hierbei handelt es sich um eine Sicherheitsfunktion, die ein versehentliches Entfernen von Dateien verhindert, die noch nicht in einem Snapshot aufgezeichnet wurden und die nicht von Git wiederhergestellt werden können.

Eine weitere nützliche Sache, die Sie möglicherweise nutzen möchten, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus Ihrer Staging-Area zu entfernen. Mit anderen Worten, Sie können die Datei auf Ihrer Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen.

Das ist besonders dann nützlich, wenn Sie vergessen haben, etwas zu Ihrer Datei .gitignore hinzuzufügen und dies versehentlich „gestaged“ haben (eine große Logdatei z.B. oder eine Reihe von .a-kompilierten Dateien). Das erreichen Sie mit der Option --cached:

Sie können Dateien, Verzeichnisse und Platzhalter-Zeichen an den Befehl git rm übergeben. Das bedeutet, dass Sie folgende Möglichkeit haben:

Beachten Sie den Backslash (\) vor dem *. Der ist notwendig, weil Git zusätzlich zur Dateinamen-Erweiterung Ihrer Shell eine eigene Dateinamen-Erweiterung vornimmt. Mit dem Befehl oben werden alle Dateien entfernt, die die Erweiterung .log im Verzeichnis log/ haben. Oder Sie können Folgendes ausführen:

Dieses Kommando entfernt alle Dateien, deren Name mit ~ endet.

Im Gegensatz zu vielen anderen VCS-Systemen verfolgt (engl. track) Git das Verschieben von Dateien nicht ausdrücklich. Wenn Sie eine Datei in Git umbenennen, werden keine Metadaten in Git gespeichert, die dem System mitteilen, dass Sie die Datei umbenannt haben. Allerdings ist Git ziemlich clever, das im Nachhinein herauszufinden – wir werden uns etwas später mit der Erkennung von Datei-Verschiebungen befassen.

Daher ist es etwas verwirrend, dass Git einen Befehl mv vorweisen kann. Wenn Sie eine Datei in Git umbenennen möchten, können Sie beispielsweise Folgendes ausführen:

Das funktioniert gut. Tatsache ist, wenn Sie so einen Befehl ausführen und sich den Status ansehen, werden Sie sehen, dass Git es für eine umbenannte Datei hält:

Unabhängig davon, ist dieser Befehl zu dem Folgenden gleichwertig:

Git erkennt, dass es sich um eine umbenannte Datei handelt, so dass es egal ist, ob Sie eine Datei auf diese Weise oder mit dem Befehl mv umbenennen. Der alleinige, reale Unterschied ist, dass git mv ein einziger Befehl ist statt deren drei – es ist eine Komfortfunktion. Wichtiger ist, dass Sie jedes beliebige Tool verwenden können, um eine Datei umzubenennen und das add/rm später aufrufen können, bevor Sie committen.