Vraag een timmerman naar zijn gereedschap en hij noemt zijn zaag. Vraag een goede webdeveloper hetzelfde en het antwoord is: Git. Versiebeheer is het fundament onder professioneel ontwikkelwerk — en toch draait een verrassend groot deel van de zakelijke websites zonder. Wijzigingen gaan dan rechtstreeks de live server op, de vorige versie bestaat alleen nog in back-ups en niemand weet meer wie wat wanneer heeft aangepast. Als website-eigenaar hoef je Git niet te kunnen bedienen, maar je wilt wél begrijpen waarom het ertoe doet — al is het maar om er bij je webbouwer naar te vragen.
Wat is versiebeheer?
Versiebeheer is een systeem dat elke wijziging aan de code van je website vastlegt: wat er veranderde, wie het deed, wanneer en waarom. Git is daarvoor de wereldstandaard. De complete geschiedenis staat in een zogeheten repository, vaak gehost op een platform als GitHub of GitLab. Vergelijk het met de versiegeschiedenis van een Google-document, maar dan strenger: elke wijziging wordt als bewust “commit”-moment vastgelegd met een omschrijving erbij, en je kunt naar elk eerder punt in de geschiedenis terug — van vijf minuten tot vijf jaar geleden.
Wat levert dat concreet op voor jouw website?
- Elke wijziging is terug te draaien. Gaat een aanpassing mis, dan staat de vorige werkende versie één commando verderop — geen paniek-restore van een complete back-up nodig.
- Meerdere mensen, geen chaos. Developers werken in eigen “branches” aan losse features en voegen die gecontroleerd samen. Niemand overschrijft elkaars werk.
- Een logboek van je website. “Sinds wanneer doet het formulier raar?” is opzoekbaar: de historie toont exact welke wijziging wanneer live ging.
- Gecontroleerd live zetten. Vanuit Git kan een wijziging automatisch naar staging en productie worden uitgerold (deployment) — geen bestanden meer via FTP over de live site heen slepen.
- Onafhankelijkheid. De code van je site staat compleet en gedocumenteerd op een neutrale plek. Wissel je van bureau, dan draag je een repository over in plaats van een zip-bestand en losse eindjes.
Hoe zit dat bij WordPress?
Bij een WordPress-site hoort niet álles in Git thuis. De vuistregel: code wél, data en bijlagen niet. In de repository horen het (child-)thema, eigen plugins en configuratie — alles wat ontwikkeld wordt. De database (berichten, bestellingen, instellingen) en de uploads-map (afbeeldingen) horen in je back-upstrategie, niet in versiebeheer; die veranderen immers door gebruik, niet door ontwikkeling. Deze scheiding is precies waarom een professionele partij zowel Git áls back-ups regelt: het zijn twee verschillende vangnetten voor twee verschillende soorten wijzigingen.
De vraag die je je webbouwer mag stellen
“Staat de code van mijn website in versiebeheer, en kan ik bij de repository?” is een volstrekt redelijke vraag — vergelijkbaar met vragen of een aannemer een bouwtekening bijhoudt. Het antwoord zegt veel over de werkwijze: wie met Git, staging en gecontroleerde deployments werkt, levert aantoonbaar reproduceerbaar werk. Vraag ook of jij (of een toekomstige partij) toegang tot de repository kunt krijgen; het is tenslotte de code van jóuw website. Een professionele partij regelt dat zonder aarzelen.
Conclusie
Versiebeheer met Git maakt van websitecode een gedocumenteerd, terugdraaibaar en overdraagbaar geheel in plaats van een verzameling bestanden op een server. Voor jou als eigenaar betekent het minder risico bij wijzigingen, een opzoekbare historie en onafhankelijkheid van één partij. Je hoeft er zelf niets voor te leren — alleen de juiste vraag te stellen aan wie aan je site werkt.