3.4 Branchen in Git - Branch workflows

branches, long-running) Omdat Git gebruik maakt van een eenvoudige drieweg-merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit houdt in dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende fases van je ontwikkelcyclus gebruikt; je kunt regelmatig vanuit een aantal mergen in andere.

Veel Git-ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun master-branch — mogelijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch develop of next genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijkerwijs altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in master. Deze wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere iss53-branch) te pullen zodra die klaar zijn, om zich ervan te overtuigen dat alle tests slagen en er geen fouten worden geïntroduceerd.

Feitelijk praten we over verwijzingen die worden verplaatst over de lijn van de commits die je maakt. De stabiele branches zijn verder stroomafwaarts in je commit-historie, en de splinternieuwe branches zijn verder naar voren in de historie.

Ze zijn misschien makkelijker voor te stellen als silo’s, waar sets van commits stapsgewijs naar een meer stabiele silo worden gepromoveerd als ze volledig getest zijn.

Je kunt dit blijven doen voor elk niveau van stabiliteit. Sommige grotere projecten hebben ook een proposed of pu (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de next of master-branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een stabieler niveau bereiken, worden ze in de branch boven hen gemerged. Nogmaals, het hebben van meerdere langlopende branches is niet noodzakelijk, maar het helpt vaak wel; in het bijzonder als je te maken hebt met zeer grote of complexe projecten.

Topic branches zijn nuttig in projecten van elke grootte. Een topic branch is een kortlopende branch die je maakt en gebruikt om een specifieke functie te realiseren of daaraan gerelateerd werk te doen. Dit is iets wat je waarschijnlijk nooit eerder met een VCS gedaan hebt, omdat het over het algemeen te duur is om branches aan te maken en te mergen. Maar in Git is het niet ongebruikelijk om meerdere keren per dag branches aan te maken, daarop te werken, en ze te verwijderen.

Je zag dit in de vorige paragraaf met de iss53 en hotfix-branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd nadat je ze gemerged had in je hoofd-branch. Deze techniek stelt je in staat om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo’s waar alle wijzigingen in die branch te maken hebben met dat onderwerp, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten-, dagen- of maandenlang bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt zijn of er aan gewerkt is.

Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op master), er wordt een branche gemaakt voor een probleem (iss91) en daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (iss91v2); weer even wordt teruggegaan naar de master branch om daar een tijdje te werken, en dan vanaf daar wordt gebrancht om wat werk te doen waarvan je niet zeker weet of het wel zo’n slim idee is (dumbidea-branch). Je commit-historie zal eruitzien als volgt:

Laten we zeggen dat je besluit dat je de tweede oplossing voor je probleem het beste vindt (iss91v2), en je hebt de dumbidea-branch aan je collega’s laten zien en het blijkt geniaal te zijn. Je kunt dan de oorspronkelijke iss91 weggooien (waardoor je commits C5 en C6 kwijt raakt), en de andere twee mergen. Je historie ziet er dan uit volgt:

We zullen in meer detail behandelen wat de verschillende mogelijke workflows zijn voor jouw Git project in Gedistribueerd Git, dus voordat je besluit welk branching schema je voor jouw volgende project wilt gebruiken, zorg dat je dat hoofdstuk gelezen hebt.

Het is belangrijk om te beseffen dat tijdens al deze handelingen, al deze branches volledig lokaal zijn. Als je aan het branchen of mergen bent, dan wordt alles alleen in jouw Git repository gedaan — dus er vindt geen server communicatie plaats.