Wijzig een bestand dat Git al bijhoudt

Je hebt een repository met één commit. README.md is gecommit en nu moet het bestand veranderen. Dat is het gewone ritme van werken met Git. Het verschilt een beetje van een eerste commit maken, want deze keer heeft Git het bestand al eerder gezien.

Wijzig het bestand

Open het opnieuw met de terminaleditor uit de eerste les:

nano -w README.md

Voeg onder de twee bestaande tekstregels een derde toe, zodat het bestand er zo uitziet:

# Garden notes

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

Sla op met Ctrl-O, druk op Enter om de naam te bevestigen en sluit af met Ctrl-X.

Modified is niet hetzelfde als untracked

git status

In de vorige les noemde git status het bestand README.md untracked. Git had dat bestand nog nooit vastgelegd en had dus niets om het mee te vergelijken. Deze keer noemt dezelfde opdracht het modified, oftewel gewijzigd.

Om dat ene woord draait deze les. Git heeft een vastgelegde versie van README.md om mee te vergelijken. Een bestand wordt tracked, dus bijgehouden, zodra je het aan de staging area toevoegt, al vóór de eerste commit. Een untracked bestand heeft daar geen vermelding. Bij deze bewerking komt de klaargezette versie nog overeen met de vorige commit. Git meldt dus het verschil tussen die opgeslagen versie en je werkbestand.

Let ook op wat Git niet deed. Je derde regel bestaat echt en staat op schijf, maar Git heeft er niets van vastgelegd. Het wacht op je opdracht, precies zoals hoofdstuk 1 beloofde.

Zet de wijziging klaar en leg haar vast

De rest is de cyclus die je al eens hebt doorlopen:

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

git add kopieert de huidige bestandsinhoud naar de staging area. Sla de git status tussen de twee opdrachten niet over: de uitvoer beschrijft de wijziging nu als klaargezet voor de volgende commit, in plaats van alleen aanwezig op schijf. git commit legt haar vervolgens vast en git log toont twee commits, met de nieuwste bovenaan.

De drie plekken op een rij

Git houdt drie versies in beeld. Je hebt de toestand van één bestand nu door alle drie heen gekopieerd:

1. De werkboom: je bestanden zoals ze op schijf staan. De derde regel kwam hier terecht toen je haar in nano opsloeg.

2. De staging area: de momentopname die je voorbereidt voor de volgende commit. git add kopieerde de huidige README.md hiernaartoe.

3. De geschiedenis: de momentopnamen die Git heeft gecommit. git commit legde de klaargezette versie vast en die vastlegging blijft bewaard.

Dit zijn geen bakken waar een wijziging fysiek tussen verhuist. Het werkbestand blijft na git add op schijf staan. Een gecommitte versie blijft in de geschiedenis terwijl je de volgende bewerkt. De versies kunnen op meer dan één overgang tegelijk verschillen.

git status vertelt welke vergelijkingen momenteel verschillen laten zien: werkboom tegenover staging area, of staging area tegenover de nieuwste commit. Als je in de rest van deze cursus twijfelt over de toestand, voer dit dan uit vóór elke andere Git-opdracht.

Daarmee heb je een complete eigen repository: twee commits, een leesbare geschiedenis en een identiteit bij beide. Hierna open je een repository die je niet zelf hebt geschreven, met al elf commits erin. Je leert lezen wat andere mensen hebben gedaan.