Werken met versiebeheer betekent niet dat het ontwikkelproces automatisch soepel verloopt. Hiervoor biedt de ‘Gitflow-strategie’ uitkomst. Met een ‘hotfix’ voorkom je dat eerder opgeloste problemen worden overschreven. Met de feature-branch voorkom je dat de ontwikkeling van grote functionaliteiten de ontwikkeling van andere functionaliteiten vertraagd. De release-branch biedt een overzicht van wanneer welke ontwikkelingen online zijn gezet.
Wat is Gitflow?
Werken met versiebeheer betekent helaas niet dat het beheer en door ontwikkelen van de code automatisch soepel verloopt. Om het ontwikkelproces soepeler te laten verlopen gebruiken we de Gitflow-strategie. Gitflow is bedacht door de Nederlander Vincent Driessen, en bij ons geïntroduceerd via Daan Kortenbach. Het is een strategie waarbij verschillende ‘branches’ worden gebruikt om overzicht en structuur te creëren. Dit is het beste uit te leggen aan de hand van een aantal voorbeelden.
Er is een probleem op de ‘live’ code
Probleem:
Er is een probleem op de ‘live’ code. Dit moet zo snel mogelijk opgelost worden. Het gebeurt hierbij vaak dat de code direct op de server wordt geplaatst, of alleen op de master. Bij het live zetten van een nieuwe versie vanuit de develop-branche wordt deze code weer overschreven. Het probleem is terug.
Oplossing:
Hotfix
Een hotfix is een branche die start vanuit master. Hier voer je de reparatie in uit. Vervolgens voeg je deze branche naar de master en de develop-branche. Zo zorg je ervoor dat snelle reparaties altijd op alle branches staan.
Wat hoort er thuis op de develop-branch?
Probleem:
Er zijn geen goede afspraken gemaakt over wat er op de develop-branch thuis hoort. Nu staan er functionaliteiten op die nog niet live gezet mogen worden. Zaken die wel af zijn kunnen nu ook niet online worden gezet, ze zijn teveel verweven met de functionaliteit die nog niet af is.
Oplossing:
Feature-branch
Zoals eerder besproken biedt de feature-branch de uitkomst. Het is belangrijk om de feature-branch pas samen te voegen met develop-branch als beide zijn afgerond en getest. Je controleert dit door eerst los de feature-branch te testen. Voorkom onbekende fouten door vervolgens alle nieuwe code van develop in jouw eigen feature-branch toe te voegen. Als dit foutloos werkt, kun je jouw feature-branch aan de develop-branch toevoegen.
Wat is wanneer online gezet?
Probleem:
Het is in het versiebeheer lastig om te zien wanneer de code online is gezet. Daarnaast kan je ook niet goed zien wanneer welke versie van de code online is gezet. Hierdoor is het bijna onmogelijk om snel een reparatie uit te voeren en deze op een nette manier terug te voeren in je versiebeheer.
Oplossing:
Develop / Master & Release-branch
Gitflow biedt 2 oplossingen voor dit probleem.
- Het werken met een master en een develop branch. Zo is duidelijk te zien wat de status van de live code is (master), en wat nog in ontwikkeling is (develop).
- Het werken met een release-branch. Elke keer dat je een nieuwe versie online wilt zetten, maak je een release branche aan vanuit de develop-branche. In deze branche ontwikkel je geen nieuwe functionaliteit, maar zet je zaken klaar die met de livegang te maken hebben. Denk hierbij aan het aanpassen van een versienummer. Ben je hiermee klaar? Dan voeg je de release-branche toe aan de master branche. Er wordt automatisch een berichtje bijgevoegd (een tag) waardoor je terug kan zien wanneer dit gebeurt is.
Structuur in je ontwikkelproces
Door het gebruik van Gitflow zorgen we er dus voor dat we structuur aanbrengen in ons ontwikkelproces zodat:
- Meerdere ontwikkelaars aan meerdere functionaliteiten tegelijkertijd kunnen werken.
- Er een duidelijke geschiedenis is van wat er geprogrammeerd is.
- Updates makkelijk en vaak online gezet kunnen worden.
- Snelle reparaties niet verloren gaan.
- Zichtbaar is wat wanneer online is gezet
