Een momentopname met een reden

Kopieën van een bestand bewaren geeft je één ding: hoe het eruitzag op een moment dat je niet meer kunt aanwijzen. Wat je eigenlijk wilt, is de toestand van de gekozen projectbestanden vastleggen, opschrijven waarom je dat deed en elke opgeslagen versie bewaren.

Gits antwoord op die wens heet een commit. Het is de moeite waard eerst het idee te leren kennen, voordat er opdrachten bij komen.

Een commit bestaat uit twee dingen die samen worden bewaard:

1. Een momentopname van de projectbestanden die je op één moment wilde opnemen. Ze legt de geselecteerde projecttoestand vast, niet alleen het ene bestand dat veranderde.

2. Een bericht waarin je hebt opgeschreven waarom.

Dat is eigenlijk het grootste deel van het idee. Bijna alles in Git draait om commits maken, lezen of ertussen bewegen.

Een geschiedenis lezen

Zo ziet een korte geschiedenis eruit als je Git vraagt die te tonen. Maak je niet druk om de exacte opmaak en probeer niets uit je hoofd te leren. Lees gewoon wat er staat.

a3f9c21  Fix the total in the summary table
7b2e880  Add the March figures
1c4d503  Start the quarterly report

Drie momentopnamen, met de oudste onderaan. Elke heeft een korte identificatiecode en het bericht dat de auteur schreef.

Vergelijk dat met report-FINAL-actually.txt. De geschiedenis beantwoordt de vraag die de bestandsnaam niet kon beantwoorden: waarom. Iemand verbeterde een totaal. Daarvoor voegde iemand maart toe. Het project heeft een verhaal en dat verhaal is opgeschreven.

Met die korte codes (a3f9c21 en dergelijke) geeft Git elke commit een naam. Ze zien er onvriendelijk uit en je zult ze vrijwel nooit uit je hoofd typen. Voor nu hoef je alleen te weten dat ze bestaan en dat elke code naar precies één momentopname verwijst.

Momentopnamen, geen verschillen

Hier moeten we een voor de hand liggende aanname bekijken, want die zorgt later vaak voor verwarring.

Je zou best kunnen denken dat een commit opslaat wat er is veranderd sinds de vorige keer. Dat is een begrijpelijke gedachte, maar het is het verkeerde beeld. Een commit legt een volledige momentopname vast van de geselecteerde projecttoestand op dat moment.

Git kan je het verschil tussen twee commits naar keuze laten zien. Dat is een van de nuttigste dingen die het doet. Maar het bepaalt dat verschil door twee volledige momentopnamen te vergelijken. Het stelt een bestand niet samen uit een keten van bewerkingen.

Dat is praktisch van belang: daarom is teruggaan naar een oude commit veilig en betrouwbaar. Je draait geen stapel wijzigingen terug in de hoop dat het resultaat klopt. Je vraagt om een foto die Git al heeft.

Waarom het bericht erbij hoort

Het is verleidelijk om het bericht als administratie te zien. Nieuwe Git-gebruikers schrijven update, fix, stuff, asdf. Iedereen heeft dat weleens gedaan.

Het argument daartegen is puur eigenbelang. Degene die je commitberichten het waarschijnlijkst leest, ben jijzelf over een maand of vier, zonder herinnering aan deze week. Het bericht is het enige deel van een commit dat geschreven is in een taal waarin je denkt. De momentopname kan laten zien hoe de code eruitzag. Alleen het bericht vertelt wat je probeerde te doen.

Je hoeft geen essays te schrijven. Fix the total in the summary table is een goed bericht: het zegt wat er veranderde en waar, in woorden die een mens gebruikt.

We komen terug op wat een bericht nuttig maakt zodra je er een paar hebt geschreven. Merk voor nu op dat Git je er iedere keer om vraagt, en dat dat bewust zo is.

Hierna bekijken we wat zo’n geschiedenis eigenlijk mogelijk maakt. Het antwoord gaat namelijk verder dan “teruggaan naar een oude versie”.