2.2 Git Grundlagen - Änderungen im Repository aufzeichnen

Das wichtigste Werkzeug, das Sie verwenden, um festzustellen, welche Dateien sich in welchem Zustand befinden, ist der Befehl git status. Wenn Sie diesen Befehl direkt nach einem Klon ausführen, sollten Sie etwas Ähnliches sehen

Das bedeutet, dass Sie ein sauberes Arbeitsverzeichnis haben; anders ausgedrückt, keine Ihrer verfolgten Dateien ist geändert. Git sieht auch keine unverfolgten Dateien, sonst würden diese hier aufgelistet. Schließlich informiert Sie der Befehl, auf welchem Branch Sie sich befinden, und teilt Ihnen mit, dass er sich nicht von demselben Branch auf dem Server unterscheidet. Vorerst ist dieser Branch immer master, was der Standard ist; Sie werden sich hier nicht darum kümmern. Git Branching wird Branches und Referenzen im Detail behandeln.

Nehmen wir an, Sie fügen eine neue Datei zu Ihrem Projekt hinzu, eine einfache README-Datei. Wenn die Datei vorher nicht existierte und Sie git status ausführen, sehen Sie Ihre unverfolgte Datei wie folgt

Sie können sehen, dass Ihre neue README-Datei unverfolgt ist, da sie unter der Überschrift "Unverfolgte Dateien" in Ihrer Statusausgabe aufgeführt ist. Unverfolgt bedeutet im Grunde, dass Git eine Datei sieht, die Sie nicht im vorherigen Schnappschuss (Commit) hatten und die noch nicht vorbereitet wurde; Git wird sie erst in Ihre Commit-Schnappschüsse aufnehmen, wenn Sie es ihm explizit sagen. Dies geschieht, damit Sie nicht versehentlich generierte Binärdateien oder andere Dateien einbeziehen, die Sie nicht einbeziehen wollten. Sie möchten README einbeziehen, also beginnen wir, die Datei zu verfolgen.

Um mit der Verfolgung einer neuen Datei zu beginnen, verwenden Sie den Befehl git add. Um die Verfolgung der README-Datei zu beginnen, können Sie dies ausführen

Wenn Sie Ihren Statusbefehl erneut ausführen, können Sie sehen, dass Ihre README-Datei jetzt verfolgt und für den Commit vorbereitet ist

Sie können erkennen, dass sie vorbereitet ist, da sie unter der Überschrift "Vorbereitete Änderungen" aufgeführt ist. Wenn Sie jetzt committen, ist die Version der Datei zum Zeitpunkt der Ausführung von git add diejenige, die im nachfolgenden historischen Schnappschuss enthalten sein wird. Möglicherweise erinnern Sie sich, dass Sie, als Sie zuvor git init ausgeführt haben, dann git add <files> ausgeführt haben – das diente dazu, die Dateien in Ihrem Verzeichnis zu verfolgen. Der Befehl git add nimmt einen Pfadnamen für eine Datei oder ein Verzeichnis; wenn es sich um ein Verzeichnis handelt, fügt der Befehl alle Dateien in diesem Verzeichnis rekursiv hinzu.

Ändern wir eine bereits verfolgte Datei. Wenn Sie eine zuvor verfolgte Datei namens CONTRIBUTING.md ändern und dann erneut den Befehl git status ausführen, erhalten Sie etwas Ähnliches wie hier

Die Datei CONTRIBUTING.md erscheint unter einer Sektion namens "Änderungen nicht für den Commit vorbereitet" – das bedeutet, dass eine verfolgte Datei im Arbeitsverzeichnis geändert wurde, aber noch nicht vorbereitet ist. Um sie vorzubereiten, führen Sie den Befehl git add aus. git add ist ein vielseitiger Befehl – Sie verwenden ihn, um die Verfolgung neuer Dateien zu beginnen, Dateien vorzubereiten und andere Dinge zu tun, wie z. B. Merge-Konflikte als gelöst zu markieren. Es kann hilfreich sein, ihn eher als "Füge diesen Inhalt präzise dem nächsten Commit hinzu" statt "Füge diese Datei zum Projekt hinzu" zu verstehen. Führen wir nun git add aus, um die Datei CONTRIBUTING.md vorzubereiten, und führen Sie dann git status erneut aus

Beide Dateien sind vorbereitet und werden in Ihren nächsten Commit aufgenommen. An diesem Punkt nehmen wir an, Sie erinnern sich an eine kleine Änderung, die Sie an CONTRIBUTING.md vornehmen möchten, bevor Sie sie committen. Sie öffnen sie erneut und nehmen diese Änderung vor, und Sie sind bereit zum Committen. Lassen Sie uns jedoch git status noch einmal ausführen

Was zum Teufel? Jetzt wird CONTRIBUTING.md sowohl als vorbereitet als auch als nicht vorbereitet aufgeführt. Wie ist das möglich? Es stellt sich heraus, dass Git eine Datei genau so vorbereitet, wie sie zum Zeitpunkt der Ausführung des Befehls git add war. Wenn Sie jetzt committen, wird die Version von CONTRIBUTING.md, wie sie war, als Sie git add zuletzt ausgeführt haben, in den Commit aufgenommen, nicht die Version der Datei, wie sie in Ihrem Arbeitsverzeichnis aussieht, wenn Sie git commit ausführen. Wenn Sie eine Datei ändern, nachdem Sie git add ausgeführt haben, müssen Sie git add erneut ausführen, um die neueste Version der Datei vorzubereiten

Während die Ausgabe von git status ziemlich umfassend ist, ist sie auch recht wortreich. Git hat auch eine Kurzstatus-Option, mit der Sie Ihre Änderungen kompakter sehen können. Wenn Sie git status -s oder git status --short ausführen, erhalten Sie eine deutlich vereinfachte Ausgabe des Befehls

Neue unverfolgte Dateien haben ein ?? daneben, neue Dateien, die zur Vorbereitungszone hinzugefügt wurden, haben ein A, geänderte Dateien haben ein M und so weiter. Es gibt zwei Spalten für die Ausgabe – die linke Spalte gibt den Status der Vorbereitungszone an und die rechte Spalte den Status des Arbeitsbaums. Zum Beispiel ist in dieser Ausgabe die Datei README im Arbeitsverzeichnis geändert, aber noch nicht vorbereitet, während die Datei lib/simplegit.rb geändert und vorbereitet ist. Die Datei Rakefile wurde geändert, vorbereitet und dann erneut geändert, sodass es Änderungen daran gibt, die sowohl vorbereitet als auch nicht vorbereitet sind.

Oft haben Sie eine Klasse von Dateien, die Git nicht automatisch hinzufügen oder Ihnen sogar als unverfolgt anzeigen soll. Dies sind im Allgemeinen automatisch generierte Dateien wie Protokolldateien oder Dateien, die von Ihrem Build-System erstellt werden. In solchen Fällen können Sie eine Datei mit Mustern zur Übereinstimmung erstellen, die .gitignore genannt wird. Hier ist eine Beispiel-.gitignore-Datei

Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf ".o" oder ".a" enden – Objekt- und Archivdateien, die das Ergebnis des Erstellens Ihres Codes sein können. Die zweite Zeile weist Git an, alle Dateien zu ignorieren, deren Namen mit einer Tilde (~) enden, die von vielen Texteditoren wie Emacs zur Markierung temporärer Dateien verwendet wird. Sie können auch ein Log-, tmp- oder pid-Verzeichnis einschließen; automatisch generierte Dokumentation; und so weiter. Das Einrichten einer .gitignore-Datei für Ihr neues Repository, bevor Sie beginnen, ist im Allgemeinen eine gute Idee, damit Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten.

Die Regeln für die Muster, die Sie in die Datei .gitignore aufnehmen können, sind wie folgt:

Glob-Muster sind wie vereinfachte reguläre Ausdrücke, die von Shells verwendet werden. Ein Sternchen (*) passt auf null oder mehr Zeichen; [abc] passt auf jedes Zeichen innerhalb der Klammern (in diesem Fall a, b oder c); ein Fragezeichen (?) passt auf ein einzelnes Zeichen; und Klammern, die durch einen Bindestrich getrennte Zeichen enthalten ([0-9]), passen auf jedes Zeichen dazwischen (in diesem Fall 0 bis 9). Sie können auch zwei Sternchen verwenden, um verschachtelte Verzeichnisse abzugleichen; a/**/z würde a/z, a/b/z, a/b/c/z usw. abgleichen.

Hier ist eine weitere Beispiel-.gitignore-Datei

Wenn der Befehl git status für Sie zu vage ist – Sie möchten 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 ihn wahrscheinlich am häufigsten verwenden, um diese beiden Fragen zu beantworten: Was haben Sie geändert, aber noch nicht vorbereitet? Und was haben Sie vorbereitet, das Sie bald committen werden? Obwohl git status diese Fragen sehr allgemein beantwortet, indem es die Dateinamen auflistet, zeigt Ihnen git diff die exakt hinzugefügten und entfernten Zeilen – sozusagen den Patch.

Nehmen wir an, Sie ändern und bereiten die README-Datei erneut vor und ändern dann die CONTRIBUTING.md-Datei, ohne sie vorzubereiten. Wenn Sie Ihren git status-Befehl ausführen, sehen Sie wieder etwas Ähnliches wie hier

Um zu sehen, was Sie geändert, aber noch nicht vorbereitet haben, geben Sie git diff ohne weitere Argumente ein

Dieser Befehl vergleicht, was sich in Ihrem Arbeitsverzeichnis befindet, mit dem, was sich in Ihrer Vorbereitungszone befindet. Das Ergebnis zeigt Ihnen die Änderungen, die Sie vorgenommen haben und die Sie noch nicht vorbereitet haben.

Wenn Sie sehen möchten, was Sie vorbereitet haben und was in Ihren nächsten Commit übernommen wird, können Sie git diff --staged verwenden. Dieser Befehl vergleicht Ihre vorbereiteten Änderungen mit Ihrem letzten Commit

Es ist wichtig zu beachten, dass git diff allein nicht alle Änderungen seit dem letzten Commit anzeigt – nur Änderungen, die noch nicht vorbereitet sind. Wenn Sie alle Ihre Änderungen vorbereitet haben, wird git diff keine Ausgabe liefern.

Als weiteres Beispiel: Wenn Sie die Datei CONTRIBUTING.md vorbereiten und sie dann ändern, können Sie git diff verwenden, um die Änderungen in der Datei zu sehen, die vorbereitet sind, und die Änderungen, die nicht vorbereitet sind. Wenn unsere Umgebung wie folgt aussieht

Jetzt können Sie git diff verwenden, um zu sehen, was noch nicht vorbereitet ist

und git diff --cached, um zu sehen, was Sie bisher vorbereitet haben (--staged und --cached sind Synonyme)

Nachdem Ihre Vorbereitungszone so eingerichtet ist, wie Sie es möchten, können Sie Ihre Änderungen committen. Denken Sie daran, dass alles, was noch nicht vorbereitet ist – alle Dateien, die Sie erstellt oder geändert haben und auf die Sie seit der Bearbeitung kein git add angewendet haben – nicht in diesen Commit übernommen wird. Sie bleiben als geänderte Dateien auf Ihrer Festplatte. In diesem Fall nehmen wir an, dass Sie bei der letzten Ausführung von git status gesehen haben, dass alles vorbereitet war, sodass Sie bereit sind, Ihre Änderungen zu committen. Die einfachste Methode zum Committen ist die Eingabe von git commit

Dies startet Ihren Editor der Wahl.

Der Editor zeigt den folgenden Text an (dieses Beispiel ist ein Vim-Bildschirm)

Sie können sehen, dass die Standard-Commit-Nachricht die letzte Ausgabe des Befehls git status auskommentiert und eine leere Zeile oben enthält. Sie können diese Kommentare entfernen und Ihre Commit-Nachricht eingeben, oder Sie können sie dort belassen, um sich daran zu erinnern, was Sie committen.

Wenn Sie den Editor beenden, erstellt Git Ihren Commit mit dieser Commit-Nachricht (wobei Kommentare und Diffs entfernt werden).

Alternativ können Sie Ihre Commit-Nachricht inline mit dem Befehl commit eingeben, indem Sie sie nach einem -m-Flag angeben, wie hier

Jetzt haben Sie Ihren ersten Commit erstellt! Sie können sehen, dass der Commit Ihnen einige Ausgaben über sich selbst geliefert hat: auf 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 Schnappschuss aufzeichnet, den Sie in Ihrer Vorbereitungszone eingerichtet haben. Alles, was Sie nicht vorbereitet haben, liegt dort immer noch als geändert; Sie können einen weiteren Commit durchführen, um es in Ihre Historie aufzunehmen. Jedes Mal, wenn Sie einen Commit durchführen, zeichnen Sie einen Schnappschuss Ihres Projekts auf, zu dem Sie später zurückkehren oder den Sie vergleichen können.

Obwohl die Vorbereitungszone unglaublich nützlich sein kann, um Commits genau so zu gestalten, wie Sie es wünschen, ist sie manchmal etwas komplexer als Sie sie für Ihren Workflow benötigen. Wenn Sie die Vorbereitungszone überspringen möchten, bietet Git eine einfache Abkürzung. Das Hinzufügen der Option -a zum Befehl git commit bewirkt, dass Git automatisch jede Datei vorbereitet, die bereits verfolgt ist, bevor der Commit durchgeführt wird, wodurch Sie den Schritt git add überspringen können

Beachten Sie, wie Sie in diesem Fall git add nicht auf die Datei CONTRIBUTING.md anwenden müssen, bevor Sie committen. Das liegt daran, dass das Flag -a alle geänderten Dateien einschließt. Das ist praktisch, aber seien Sie vorsichtig; manchmal wird dieses Flag dazu führen, dass Sie unerwünschte Änderungen einschließen.

Um eine Datei aus Git zu entfernen, müssen Sie sie aus Ihren verfolgten Dateien entfernen (genauer gesagt, aus Ihrer Vorbereitungszone entfernen) und dann committen. Der Befehl git rm tut dies und entfernt auch die Datei aus Ihrem Arbeitsverzeichnis, sodass Sie sie beim nächsten Mal nicht als unverfolgte Datei sehen.

Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem Bereich "Änderungen nicht für den Commit vorbereitet" (d. h. nicht vorbereitet) in der Ausgabe von git status

Dann, wenn Sie git rm ausführen, wird die Entfernung der Datei vorbereitet

Beim nächsten Commit ist die Datei weg und wird nicht mehr verfolgt. Wenn Sie die Datei geändert oder sie bereits zur Vorbereitungszone hinzugefügt haben, müssen Sie die Entfernung mit der Option -f erzwingen. Dies ist eine Sicherheitsfunktion, um versehentliches Entfernen von Daten zu verhindern, die noch nicht in einem Schnappschuss aufgezeichnet wurden und die nicht aus Git wiederhergestellt werden können.

Eine weitere nützliche Sache, die Sie vielleicht tun möchten, ist, die Datei in Ihrem Arbeitsbaum zu belassen, sie aber aus Ihrer Vorbereitungszone zu entfernen. Mit anderen Worten, Sie möchten die Datei auf Ihrer Festplatte behalten, aber nicht mehr, dass Git sie verfolgt. Dies ist besonders nützlich, wenn Sie vergessen haben, etwas zu Ihrer .gitignore-Datei hinzuzufügen und sie versehentlich vorbereitet haben, wie eine große Protokolldatei oder eine Reihe von kompilierten .a-Dateien. Um dies zu tun, verwenden Sie die Option --cached

Sie können Dateien, Verzeichnisse und Dateimuster an den Befehl git rm übergeben. Das bedeutet, Sie können Dinge tun wie

Beachten Sie den Backslash (\) vor dem *. Dies ist notwendig, weil Git neben der Dateinamenerweiterung Ihrer Shell auch seine eigene Dateinamenerweiterung durchführt. Dieser Befehl entfernt alle Dateien mit der Erweiterung .log im Verzeichnis log/. Oder Sie können so etwas tun

Dieser Befehl entfernt alle Dateien, deren Namen auf eine ~ enden.

Im Gegensatz zu vielen anderen VCSs verfolgt Git Datei-Verschiebungen nicht explizit. Wenn Sie eine Datei in Git umbenennen, werden keine Metadaten in Git gespeichert, die ihm sagen, dass Sie die Datei umbenannt haben. Git ist jedoch ziemlich schlau darin, dies nachträglich herauszufinden – wir werden die Erkennung von Datei-Verschiebungen etwas später behandeln.

Daher ist es etwas verwirrend, dass Git einen mv-Befehl hat. Wenn Sie eine Datei in Git umbenennen möchten, können Sie so etwas ausführen

und es funktioniert einwandfrei. Tatsächlich, wenn Sie so etwas ausführen und sich den Status ansehen, werden Sie sehen, dass Git dies als umbenannte Datei betrachtet

Dies entspricht jedoch der Ausführung von etwas wie dem Folgenden

Git stellt implizit fest, dass es sich um eine Umbenennung handelt, daher spielt es keine Rolle, ob Sie eine Datei auf diese Weise oder mit dem Befehl mv umbenennen. Der einzige wirkliche Unterschied ist, dass git mv ein Befehl anstelle von drei ist – es ist eine Komfortfunktion. Wichtiger ist, dass Sie jedes Werkzeug verwenden können, um eine Datei umzubenennen, und die add/rm später vor dem Commit behandeln können.