Versiebeheer klinkt als een teamsport. Dat is het niet. De meeste handleidingen hebben het over pull requests, code reviews en merge conflicts tussen collega's, waardoor solobouwers aannemen dat het hele systeem niet op hen van toepassing is. Die aanname kost mensen hun werk. Een individuele ontwikkelaar maakt net zo vaak dingen kapot als een team, alleen is er niemand in de buurt om het op te merken voordat het wordt uitgebracht.
Waarom solobouwers versiebeheer overslaan
Veel mensen vermijden versiebeheer omdat ze denken dat het bestaat om andere mensen aan te sturen. Daarom slaan ze bestanden op als "definitief", dan "definitief2", dan "definitief_ECHT", en noemen dat een systeem. Deze aanpak werkt totdat een wijziging iets kapotmaakt en niemand meer weet welk bestand de laatste werkende versie bevatte. Een aantal vrienden die als solo-ontwikkelaar werken, is verrast om te horen dat sommige mensen versiebeheer zelfs gebruiken voor projecten waar zij de enige ontwikkelaar zijn, en in plaats daarvan gewoon de projectmap kopiëren voor elke release of grote mijlpaal.
Daarnaast beschouwen sommige bouwers versiebeheer als extra overhead voor een project dat al genoeg tijd kost. Maar in de praktijk is het tegendeel meestal waar. Wat de initiële installatiekosten ook zijn, programmeren is veel makkelijker mét versiebeheer dan zonder. De installatie kost minuten. De gewoonte betaalt zich terug zodra een wijziging de eerste keer misgaat.
De echte barrière is dus niet de moeite. Het is het geloof dat versiebeheer pas nuttig is zodra er anderen bij het project komen. Dat geloof negeert wat solowerk daadwerkelijk kapotmaakt: vergeten wijzigingen, overschreven bestanden en code die gisteren werkte maar vandaag niet meer.
Wat versiebeheer je daadwerkelijk oplevert
In de kern is versiebeheer een systeem dat wijzigingen in een bestand of verzameling bestanden in de loop van de tijd vastlegt, waardoor ontwikkelaars wijzigingen kunnen bijhouden, beheren en indien nodig ongedaan maken. Die omschrijving klinkt technisch, maar het dagelijks gebruik is eenvoudig. Je slaat een momentopname van je werk op, een commit genaamd, telkens wanneer je iets afrondt dat de moeite waard is om te bewaren.
Door deze gewoonte zijn fouten niet langer permanent. Als een wijziging je project kapotmaakt, bekijk je de geschiedenis en ga je terug naar de versie die wel werkte. Als er iets misgaat, kun je eenvoudig terugkeren naar een eerdere werkende staat. Geen paniek, niet opnieuw opbouwen uit je hoofd, niet hopen dat je nog weet hoe de oude code eruitzag.
Bovendien geeft versiebeheer je een overzicht van je eigen beslissingen. Weken later kun je terugkijken en precies zien wat er is veranderd en waarom, mits je duidelijke commit-berichten schrijft. Dit verandert je projectgeschiedenis in documentatie die je niet apart hoefde te schrijven, wat belangrijker is dan het klinkt zodra een project groter wordt dan een paar bestanden.
Gewoontes opbouwen die later schalen
Alleen werken betekent niet dat je altijd alleen zult blijven werken. Projecten groeien, zijprojecten worden echte producten en hobbycode verandert soms in iets waar anderen op vertrouwen. Wanneer je project van de grond komt en je een team hebt dat eraan werkt, verloopt je ontwikkelproces veel soepeler omdat je de goede gewoontes en best practices al op orde hebt.
Kleine, frequente commits vormen de kern van die gewoonte. In plaats van één gigantische update aan het eind van de dag op te slaan, breek je je werk in stukjes die je in één zin kunt beschrijven. Maak kleine commits; een hele dag werk met meerdere functies en bugfixes zou eigenlijk uit minstens tien afzonderlijke commits moeten bestaan. Dit maakt je geschiedenis leesbaar en maakt het makkelijker om een enkele fout te isoleren.
Op dezelfde manier kun je met branching riskante ideeën testen zonder je hoofdcode aan te raken. Je probeert een experiment op een aparte branch, en als het mislukt, verwijder je de branch en is er niets verloren. Je kunt branches aanmaken om te experimenteren of nieuwe functies te ontwikkelen zonder de hoofdcodebasis te verstoren. Voor een solobouwer neemt dit de angst weg die mensen er normaal gesproken van weerhoudt om nieuwe ideeën uit te proberen.
Het systeem eenvoudig houden
Niets hiervan vereist strikte regels die zijn overgenomen van een groot technisch team. Soloprojecten hebben geen goedkeuringsworkflows of vijf soorten branches nodig. Als solo-ontwikkelaar is het prima om direct op de main branch te werken, een branch af te splitsen als je iets bijzonder riskants doet en af en toe een commit te labelen (taggen) bij het maken van een release, aangezien broncodebeheer bedoeld is om je te helpen, niet om je te beperken.
Wat belangrijker is, is consistentie. Commit vaak, schrijf een korte notitie over wat er is veranderd en push je werk naar een plek buiten je eigen machine. Een gehoste repository fungeert als back-up, wat belangrijker is dan de meeste mensen beseffen totdat een laptop het begeeft. Het automatisch laten back-uppen van codewerk naar een dienst zoals GitHub neemt weer een reden weg waarom een slechte dag uitloopt op een verloren project.
Uiteindelijk blijven de tools hetzelfde, of je nu met tien mensen werkt of alleen. Git blijft de standaardkeuze en de meeste editors ondersteunen het inmiddels zonder extra installatie. De discipline is kleinschaliger voor een soloproject, maar niet optioneel. Het is wat een project dat je kunt vertrouwen scheidt van een project waar je je stilletjes zorgen over maakt.
Conclusie: versiebeheer als een gewoonte die het waard is om te behouden
Versiebeheer is geen gunst die je aan teamgenoten verleent. Het is een gewoonte die je eigen werk beschermt tegen je eigen fouten. Elke commit is een punt waar je naar terug kunt keren, elke branch is een veilige plek om te experimenteren en elke back-up is een verzekering tegen een slechte middag. Begin klein: installeer Git, commit je volgende wijziging en push deze naar een plek buiten je laptop. Zodra versiebeheer routine wordt, denk je er niet meer over na en vertrouw je er simpelweg op dat je project veilig is.
