Wat een geschiedenis mogelijk maakt

“Teruggaan naar een oude versie” is het antwoord dat de meeste mensen geven als je vraagt waar versiebeheer voor dient. Het klopt, maar het is het kleinste deel.

Dit is wat een geschiedenis je werkelijk oplevert.

Je kunt teruggaan

Je kunt de exacte bestandsversies terughalen die in een beschikbare commit zijn vastgelegd, ook wanneer wijzigingen aan meerdere bestanden samen zijn opgeslagen. Bestanden en bewerkingen die je nooit hebt opgenomen, vallen buiten die momentopname.

Je kunt ook even teruggaan om te kijken, zonder daar te blijven. Dat verwachten mensen vaak niet. Een kijkje nemen in de versie van vorige maand is iets gewoons waar weinig van afhangt, geen reddingsoperatie.

Je kunt zien wat er veranderde

Vraag Git om het verschil tussen twee commits naar keuze en het laat precies zien welke regels erbij kwamen en verdwenen.

Dankzij die mogelijkheid kun je het werk van iemand anders beoordelen. Zo controleer je ook je eigen werk voordat je het vastlegt, en dat blijkt een nuttige gewoonte. “Laat alles zien wat ik zo ga committen” vangt verrassend veel fouten af, waaronder debugregels die je wilde verwijderen en een wachtwoord dat je niet in een bestand wilde typen.

Je kunt vinden wanneer iets stukging

Deze mogelijkheid is misschien wel de waardevolste. Het is ook het lastigst om die te waarderen voordat ze je een keer heeft gered.

In maart werkt iets. In juni niet meer. Niets wat je voor je ziet verklaart waarom.

Met een geschiedenis heb je de toestanden die je bewust hebt vastgelegd. Je kunt een werkende versie vergelijken met een kapotte, de commit vinden waarin het vastgelegde gedrag veranderde, het bericht lezen en de gewijzigde regels bekijken. Als die commit meerdere bewerkingen bevatte, moet je mogelijk nog onderzoeken welke ervan het probleem veroorzaakte.

Zonder geschiedenis redeneer je over een programma waarvan je het verleden niet kunt zien.

Je kunt zonder angst werken

De andere drie zijn handig. Deze verandert hoe je werkt.

Als je uitgangssituatie is gecommit, wordt iets proberen minder kostbaar. Je kunt een deel herschrijven of iets verwijderen dat overbodig lijkt en het experiment daarna met de opgeslagen versie vergelijken. Mislukt het, dan kun je de vastgelegde bestanden herstellen nadat je hebt gecontroleerd welke niet-gecommitte wijzigingen je wilt weggooien.

Vergelijk dat met een project dat je niet hebt gecommit. Daar heeft elke grote wijziging een verborgen prijs: als dit misgaat, kan ik misschien niet terug. Dat houdt je niet tegen om te werken. Het zorgt dat je kleinere, voorzichtigere stappen zet dan je anders zou doen, meestal zonder dat je het merkt.

Mensen die vertrouwd zijn met Git durven merkbaar meer met hun werk. Dat ligt niet aan hun persoonlijkheid. Ze hebben een vangnet en weten precies hoe het werkt.

De eerlijke kanttekening

Niets hiervan gebeurt automatisch.

Git houdt je map niet in de gaten om je werk onderweg vast te leggen. Jij beslist wanneer je een commit maakt en jij schrijft het bericht. Een project waarin iemand elk uur doordacht commit, krijgt een leesbare geschiedenis. Een project waarin iemand eens per maand commit met het bericht updates heeft technisch gezien een geschiedenis, maar je hebt er weinig aan.

De vaardigheid is dus meer dan de opdrachten kennen. Je ontwikkelt gevoel voor wanneer een stuk werk het vastleggen waard is en wat je erbij schrijft. Dat leer je door het te doen. In het volgende hoofdstuk begin je daarmee, in een echte repository.