Op dezelfde manier waarop je een boek schrijft, zo wordt ook een website ‘geschreven’. Ergens wordt op een leeg vel gestart met het schrijven van code. Er wordt een feature gemaakt, dingen worden aangepast en stukken code worden soms opnieuw geschreven. Er verandert dus veel in de ‘codebase’ van jouw digitale kanaal. En er werken vaak meerdere developers aan dezelfde website. Soms werken ze allemaal aan hun eigen feature, maar soms ook allemaal aan dezelfde. Het kan zelfs voorkomen dat ze in hetzelfde bestand moeten werken.

Er ontstaan op die manier allemaal verschillende versies van dezelfde website die bij meerdere developers op de computer of server staat. Dat wordt erg onoverzichtelijk en de kans dat er fouten gemaakt worden of dat er bugs ontstaan in de code is groot. Dat voorkom je door goed gebruik te maken van versiebeheer.

Git als tool voor versiebeheer

Met versiebeheer zorg je ervoor dat iedereen die aan je project werkt zijn werkzaamheden op één centraal punt (de repo of repository) opslaat, dat wijzigingen in bestanden worden bijgehouden en dat alle code bij elkaar komt in één versie. Voor versiebeheer heb je bepaalde tools nodig. De belangrijkste tool is die voor het versiebeheer zelf. Git wordt in de developmentwereld vaak gebruikt voor het versiebeheer.

Git werkt met zogenaamde ‘branches’, oftewel vertakkingen. In die branches zitten bepaalde versies van de codebase of bepaalde features waaraan gewerkt wordt maar die nog niet klaar zijn. De benaming van branches staat vrij, maar veel repositories kennen branches waarin de live versie van de website staat (de master branch), een versie die op development of staging draait (de development branch) en er zijn branches waarin alleen de code van een bepaalde feature of template staat. Uniforme naamgeving en consequent gebruik van branches is binnen een development team overigens heel belangrijk. Dat creëert duidelijkheid en reduceert de kansen op fouten.

Wijzigingen van de code: commits

Een developer werkt een aantal dagen aan een bepaalde feature of aan bepaalde templates. Daarbij wordt het werk vaak opgedeeld in stukjes. Eerst wordt de header gemaakt, dan de body, dan de footer, dan het contactformulier enz. Al die toevoegingen en aanpassingen zorgen voor veranderingen in de code. Die veranderingen wil je bijhouden. Zo kun je heel goed zien wat je precies hebt gemaakt en kun je ook terugkijken hoe bepaalde zaken op een eerder punt in de tijd zijn ontwikkeld.

De wijzigingen van de code wordt bijgehouden in ‘commits’. Het is goed gebruik om elke stap die je hebt gezet in de ontwikkeling van een feature te ‘committen’, oftewel op te slaan in de Git-repository. Iedere commit bevat ook een ‘commit message’. Dat is een korte omschrijving van de werkzaamheden die zijn verricht. Zo hou je een mooi overzicht van de voortgang en kunnen collega developers goed zien welke code waarvoor dient.

Samenbrengen van verschillende branches

Door in branches te werken kunnen verschillende developers makkelijker simultaan aan verschillende features van de website werken, zonder dat ze elkaars code overschrijven. Maar, op een bepaald moment is een feature klaar of is het template af en dan moet alle code natuurlijk bij elkaar komen. Dat is het moment waarop je verschillende branches bij elkaar brengt waardoor een nieuwe versie van de codebase ontstaat. Het samenbrengen van branches heet ‘mergen’.

Je merged verschillende feature branches bijvoorbeeld eerst allemaal in de development branch. De development branch deploy je naar een development omgeving zodat alles als coherent geheel goed getest kan worden. Als je alle nieuwe features hebt getest en alles werkt naar behoren, dan kun je naar de staging omgeving deployen. Als daar ook alles goed werkt, dan kan alles naar de live-omgeving. Op de live omgeving draait uitsluitend de master branch. Dus als alles goed werkt op staging, merge je de development branch in de master branch en de master branch deploy je naar de live omgeving.

Mocht er onverhoopt toch op live iets niet goed gaan, dan kun je met Git dus heel makkelijk een versie terug gaan en die deployen. Zie hier de kracht van goed versiebeheer.

Hieronder in het plaatje zie je een visuele representatie van een repository met daarin branches die weer bij elkaar komen (de gekleurde lijnen), commits en commit messages. Je ziet ook in een commit welke code is toegevoegd (het groen gearceerde vlak met plusjes ervoor).

sourcetree example
Een screenshot van Sourcetree, een GUI voor het werken met Git. Bron: https://blog.sourcetreeapp.com/2017/01/27/sourcetree-for-windows-2-0-is-now-in-beta/

Waarom is het werken met versiebeheer en Git zo belangrijk?

Je hebt nu een globaal beeld van hoe versiebeheer werkt. Je hoeft dus niet meer verschrikt op te kijken als jouw bureau het heeft over branches, Git en commits want nu weet je precies wat ze ermee bedoelen. De meeste bureau’s en professionele webagencies gebruiken allemaal Git of een vorm van versiebeheer. Hieronder kort waarom het zo belangrijk is om versiebeheer te gebruiken:

  • Met versiebeheer kunnen meerdere developers makkelijker aan verschillende of dezelfde features, bestanden en codebase werken zonder dat ze elkaar in de weg zitten. Met Git hebben ze een krachtige tool waarmee ze alle gemaakte code op de juiste manier bij elkaar kunnen brengen. Ze kunnen eenvoudig wijzigingen in de codebase inzien en bijhouden.
  • Er is een goed overzicht van de codebase en de wijzigingen daarin. Zo kun je bijvoorbeeld beter bugs opsporen of bepalen welk stukje code nog niet helemaal goed werkt.
  • Werken met Git en versiebeheer sluit helemaal aan op SCRUM en Agile werken. Je schrijft user stories en use cases uit, daar maak je tickets van in de backlog en die tickets koppel je weer aan branches in Git. Zo hou je een goed overzicht welke code en commits bij welke tickets horen.
  • Het geeft veel duiding aan de codebase. Developers kunnen per wijziging / commit goed zien wat er is gedaan en met de juiste commit message erbij wordt ook duidelijk waarom en met welk doel.
  • Je hebt altijd een back-up van je codebase, ook van code uit het verleden. Met een Git repository hoef je je nooit meer zorgen te maken of er nog wel een back-up is van je codebase. Alles staat in de repository, ook de versie van je site van een jaar geleden.