Eine Datei ändern, die Git bereits verfolgt

Du hast ein Repository mit einem Commit. README.md ist committet, und jetzt muss sich die Datei ändern. Das ist der gewöhnliche Rhythmus der Arbeit mit Git. Er unterscheidet sich etwas vom ersten Commit, denn diesmal kennt Git die Datei bereits.

Die Datei ändern

Öffne sie erneut mit dem Terminaleditor aus der ersten Lektion:

nano -w README.md

Füge unter den beiden vorhandenen Zeilen eine dritte hinzu, sodass die Datei so aussieht:

# Garden notes

The first repository will keep this file's history.
Beds are numbered from the gate.

Speichere mit Ctrl-O, bestätige den Namen mit Enter und verlasse nano dann mit Ctrl-X.

Modified ist nicht dasselbe wie untracked

git status

In der letzten Lektion bezeichnete git status die Datei README.md als untracked. Git hatte die Datei noch nie aufgezeichnet und besaß deshalb keinen Vergleichsstand. Diesmal nennt derselbe Befehl sie modified.

Um dieses eine Wort geht es in dieser Lektion. Git hat eine aufgezeichnete Version von README.md, mit der es vergleichen kann. Eine Datei gilt als tracked, also verfolgt, sobald du sie zur Staging-Area hinzufügst, noch vor ihrem ersten Commit. Eine untracked, also nicht verfolgte Datei hat dort keinen Eintrag. Bei dieser Bearbeitung stimmt die bereitgestellte Version noch mit dem vorherigen Commit überein. Git meldet deshalb den Unterschied zwischen dieser gespeicherten Version und deiner Arbeitsdatei.

Beachte auch, was Git nicht getan hat. Deine dritte Zeile ist tatsächlich auf dem Datenträger gespeichert, und Git hat nichts davon aufgezeichnet. Es wartet auf deinen Auftrag, genau wie in Kapitel 1 versprochen.

Die Änderung bereitstellen und dann aufzeichnen

Der Rest ist der Ablauf, den du schon einmal durchlaufen hast:

git add README.md
git status
git commit -m "Note how the beds are numbered"
git log

git add kopiert den aktuellen Dateiinhalt in die Staging-Area. Die Ausgabe von git status zwischen den beiden Befehlen solltest du lesen, statt sie zu überspringen: Sie beschreibt die Änderung jetzt als für den nächsten Commit vorgesehen, nicht bloß als auf dem Datenträger vorhanden. git commit zeichnet sie dann auf, und git log zeigt zwei Commits, den neuesten oben.

Die drei Bereiche mit Namen

Git behält drei Versionen im Blick. Du hast den Zustand einer Datei jetzt durch alle drei hindurch kopiert:

1. Der Arbeitsbaum: deine Dateien, so wie sie auf dem Datenträger liegen. Die dritte Zeile kam hier an, als du sie in nano gespeichert hast.

2. Die Staging-Area: die Momentaufnahme, die du für den nächsten Commit vorbereitest. git add hat die aktuelle README.md dorthin kopiert.

3. Der Verlauf: die Momentaufnahmen, die Git committet hat. git commit hat die bereitgestellte Version aufgezeichnet. Diese Aufzeichnung bleibt erhalten.

Das sind keine Kisten, zwischen denen eine Änderung physisch wandert. Nach git add bleibt die Arbeitsdatei auf dem Datenträger. Eine committete Version bleibt im Verlauf, während du die nächste bearbeitest. Die Versionen können sich an mehreren dieser Übergänge gleichzeitig unterscheiden.

git status sagt dir, bei welchen Vergleichen es gerade Unterschiede gibt: zwischen Arbeitsbaum und Staging-Area oder zwischen Staging-Area und neuestem Commit. Wenn dich im weiteren Kurs etwas verunsichert, führe diesen Befehl vor jedem anderen Git-Befehl aus.

Damit hast du ein vollständiges eigenes Repository: zwei Commits, einen verständlichen Verlauf und eine Identität an beiden Commits. Als Nächstes öffnest du ein Repository, das du nicht selbst geschrieben hast und das bereits elf Commits enthält. Du lernst, die Arbeit anderer zu lesen.