Bruikbaar versiebeheer met Git

Bij bestaande projecten zie ik vaak een branch tree met soms meer dan 7 branches naast elkaar, die vanaf elkaar zijn ontstaan en in een andere branch zijn teruggemerget. Is een dergelijk web van branches nog bruikbaar? Of de vraag is misschien; kan dit beter?

Kan dit beter?

– Ja dat kan!
Met een paar simpele richtlijnen is het mogelijk om een branch tree te krijgen met maar 1 develop tak, met alleen maar branches voor de features die op dat moment in ontwikkeling zijn en om die reden nog niet naar develop gemerget moeten worden. Bij het gedeelte over ‘develop branch’ leg ik uit waarom er een develop branch is en waarom ‘work in progress‘ daar niet naartoe gemerget zou moeten worden.

Waarom?

Waarom moeilijk doen als het makkelijk kan?

– het is natuurlijk heel makkelijk om een puinhoop te maken. Maar dan is het moeilijk om nog iets terug te vinden. En het is dan niet alleen moeilijk, maar ook vervelend om de boel te moeten opruimen. Daarom is het belangrijk om te voorkomen dat het een puinhoop wordt.

Waarom gebruiken we überhaupt versiebeheer?

– versiebeheer met Git is niet alleen handig voor review en samenwerking. Versie beheer is ook handig om te zien wat er wanneer gebeurd is. Als bijvoorbeeld iets niet meer werkt, kun je altijd terug naar het moment waarop het nog wel werkte. Met Git is dan makkelijk te zien wat er is gebeurd en hoe het kan worden opgelost.

De ‘develop’ branch

De develop branch is de tak die werkende code bevat. Dat betekent code die is gereviewd, is goedgekeurd en is getest. Bij het starten met bouwen van nieuwe functionaliteit is het wel zo handig om een applicatie te hebben die werkt. Bij het maken van een feature branch is het daarom belangrijk dat de feature branch aftakt van een werkende develop branch. Daarom zou een feature branch ‘in progress’ dus ‘nooit’ naar develop gemerget moeten worden.

De ‘master’ branch

Als de develop branch dusdanig ver in ontwikkeling is dat de applicatie bruikbaar is (gedeployed kan worden), kan develop naar een master branch worden gemerget.

Richtlijnen voor een nette Git tree

Bij het starten van nieuw werk maak je daarvoor een nieuwe feature branch aan.
Om een feature branch te starten vanaf develop moet eerst develop lokaal up-to-date zijn.
1. Dus check-out develop en pull
2. Start nieuwe feature branch
Belangrijk is dat de feature branch zo lang mogelijk lokaal blijft en niet gepusht wordt naar remote, omdat in latere stappen dan gepusht moet worden met ‘force’, waardoor collega’s hun werk zouden kunnen verliezen.
Als het werk op de nieuwe feature branch klaar is, zijn er ondertussen door collega ook allerlei branches aangemaakt en naar develop gemerget. Daarom moet je eerst rebasen op develop zodat jouw aanpassingen het meest recent zijn in de Git tree.
3. Check out develop en pull
4. Check out de feature branch en rebase op develop
5. Los merge-conflicten op
6. Check out develop en merge de feature branch in develop en push develop
Gebruik bij het mergen ‘fast-forward’ mergen. Fast-forward mergen zorgt ervoor dat, indien mogelijk, de commit in de tree wordt geplaatst alsof het op develop was gecommit.
Bij mergen zonder fast-forward ontstaat een kleine aftakking met daarin de commit en een merge commit. Twee commits dus! De tweede commit met de opmerking dat er is gemerget is naar mijn idee behoorlijk nutteloos en zorgt alleen maar voor een klein beetje rommel in de Git tree.
Als een feature branch eenmaal is gemerget staat ie op develop en is de aftakking niet meer nodig.
7. delete de feature branch (als je ooit gepusht hebt naar remote, voor bijvoorbeeld een pull request, dan ook van remote verwijderen)

Nuttige commits

Tot slot nog een opmerking over een commit. Toen ik begon met Git, committe ik elke aanpassing die ik deed, zodat ik zeker wist dat alles terug te vinden was.
Deze manier heeft tot gevolg dat een kleine aanpassing van bijvoorbeeld een tekst uit 3 of soms meer commits bestaat. De eerste was het veranderen van de tekst, de tweede een spelfout in de aanpassing en de derde commit was het herstellen van een niet lekker lopende zin door de tekstaanpassing.
Wat heb je aan alle 3 de commits als je de wijziging uiteindelijk nodig hebt om terug te vinden? Wat gebeurde nu in welke van de 3 commits? En wat is nu het uiteindelijke resultaat?
Het terugvinden wordt dus moeilijker, omdat er veel meer commits zijn om in te zoeken dan nodig. Door gebruik te maken van een amend commit, bewerk je de vorige commit.
Door gebruik te maken van amend committen houd je alle aanpassingen die nodig zijn in 1 commit. Dat behoud ook meteen het overzicht. Daarmee hebben we een laatste richtlijn:
8. Gebruik niet meer dan 1 commit voor een feature

Conclusie

Te veel commits per feature zorgt voor onbruikbare commits. Zonder rebasen ontstaan allerlei branches en merge commits, waar je in principe niks aan hebt. De hiervoor besproken 8 stappen zorgen voor een overzichtelijk en bruikbaar versiebeheer. Het lijkt meer werk om elke commit te moeten amenden, features te moeten rebasen en altijd de lokale develop up-to-date te moeten houden, maar bij veel doen, wordt het een gewoonte. Het kost dan net zoveel tijd en moeite als zonder nadenken te committen en te mergen. Het kost in het laatste geval zelfs meer tijd om iets terug te vinden of om uit te zoeken welke trees nog open staan of om terug te vinden wat er precies gedaan is waardoor de applicatie niet meer werkt.

Tweet about this on TwitterShare on LinkedIn

Reacties

Het e-mailadres wordt niet gepubliceerd.

*