Gitflow-workflow

Gitflow is een oude Git-workflow die oorspronkelijk een ontwrichtende en nieuwe strategie was voor het beheren van Git-branches. Gitflow is in populariteit gedaald ten gunste van workflows op basis van trunks. Deze worden nu beschouwd als beproefde methoden voor moderne continue softwareontwikkeling en DevOps-handelswijzen. Gitflow kan ook uitdagend zijn in combinatie met CI/CD. In dit bericht wordt Gitflow beschreven voor historische doeleinden.

Wat is Gitflow?

Gitflow is een alternatief Git branching-model dat het gebruik van functie-branches en meerdere primaire branches omvat. Het werd voor het eerst gepubliceerd door Vincent Driessen tijdens nvie, die de tool ook populair maakte. In vergelijking met de op trunk-gebaseerde ontwikkeling heeft Gitflow talrijke, langer bestaande branches en grotere commits. Onder dit model maken ontwikkelaars een functie-branch aan en vertragen ze het samenvoegen ervan met de main-trunk-branch totdat de functie is voltooid. Deze langer gebruikte functie-branches vereisen meer samenwerking voor het samenvoegen. Ook is er een grotere kans op afwijkingen van de trunk-branch. Bovendien kunnen ze tegenstrijdige updates met zich meebrengen.

Gitflow kan worden gebruikt voor projecten met een geplande releasecyclus en voor de beproefde DevOps-methodecontinue levering. Deze workflow voegt geen nieuwe concepten of opdrachten toe die verder gaan dan wat nodig is voor de functie-branch-workflow. In plaats daarvan kent deze zeer specifieke rollen toe aan verschillende branches en definieert de workflow hoe en wanneer ze moeten communiceren. Naast functiebranches maakt het gebruik van afzonderlijke branches voor het voorbereiden, onderhouden en opnemen van releases. Natuurlijk kun je ook gebruikmaken van alle voordelen van de workflow voor functiebranches: pull-aanvragen, geïsoleerde experimenten en efficiëntere samenwerking.

Hoe het werkt

Ontwikkelen en hoofd-branches

In plaats van één main-branch gebruikt deze workflow twee branches om de geschiedenis van het project vast te leggen. De main-branch slaat de officiële versiegeschiedenis op; de branch develop dient als integratiebranch voor functies. Het is ook handig om alle commits in de main-branch te taggen met een versienummer.

De eerste stap is het aanvullen van de standaard main-branch met een develop-branch. Een eenvoudige manier om dit te doen, is als volgt. Eén ontwikkelaar maakt lokaal een lege develop-branch en pusht deze naar de server:

1git branch develop
2git push -u origin develop

Deze branch zal de volledige geschiedenis van het project bevatten; main bevat op zijn beurt een verkorte versie. Andere ontwikkelaars moeten nu de centrale repository klonen en een tracking-branch aanmaken voor develop.

Wanneer je de 'git-flow'-extensiebibliotheek gebruikt, zal het uitvoeren van git flow init op een bestaande repo de develop-branch aanmaken:

1$ git flow init
2
3Initialized empty Git repository in ~/project/.git/
4No branches exist yet. Base branches must be created now.
5Branch name for production releases: [main]
6Branch name for "next release" development: [develop]
7
8How to name your supporting branch prefixes?
9Feature branches? [feature/]
10Release branches? [release/]
11Hotfix branches? [hotfix/]
12Support branches? [support/]
13Version tag prefix? []
14
15$ git branch
16* develop
17 main

Functie-branches

Stap 1: De repository aanmaken

Elke nieuwe functie moet zich in zijn eigen branch bevinden, die naar de centrale repository kan worden gepusht voor back-up/samenwerking. Maar in plaats van een branch van main te maken, gebruiken functie-branchesdevelop als hun bovenliggende branch. Wanneer een functie is voltooid, wordt deze weer samengevoegd in 'develop'. Functies mogen nooit rechtstreeks communiceren met main.

Merk op dat functie-branches gecombineerd met de develop-branch voor alle doeleinden de functie-branch-workflow is. De Gitflow-workflow gaat echter verder.

Functie-branches worden over het algemeen gemaakt naar de nieuwste develop-branch.

Een functie-branch maken

Zonder de 'git-flow'-extensies:

1git checkout develop
2git checkout -b feature_branch

Met de 'git-flow'-extensie:

1git flow feature start feature_branch

Ga verder met je werk en gebruik Git zoals je gewoonlijk zou doen.

Een functie-branch voltooien

Als je klaar bent met het ontwikkelingswerk voor de functie, moet je de feature_branch samenvoegen in develop.

Zonder de 'git-flow'-extensies:

1git checkout develop
2git merge feature_branch

Met de 'git-flow'-extensies:

1git flow feature finish feature_branch

Release-branches

Zodra develop voldoende functies heeft verworven voor een release (of als een vooraf bepaalde releasedatum nadert), vertak je een release-branch van develop. Met het maken van deze branch start je de volgende releasecyclus. Daarom kunnen er na dit punt geen nieuwe functies worden toegevoegd. Deze branch moet alleen worden gebruikt voor probleemoplossingen, het genereren van documentatie en andere taken die op deze versie zijn gericht. Zodra de release-branch klaar is voor verzending, wordt deze samengevoegd in main en getagd met een versienummer. Bovendien moet hij weer worden samengevoegd in develop, die mogelijk is doorontwikkeld sinds de release werd gestart.

Door een speciale branch te gebruiken om releases voor te bereiden, kan één team de huidige release verfijnen, terwijl een ander team doorwerkt aan functies voor de volgende release. Het leidt ook tot goed gedefinieerde ontwikkelingsfasen (het is bijvoorbeeld gemakkelijk om te zeggen: 'Deze week bereiden we versie 4.0 voor', die vervolgens daadwerkelijk te zien is in de structuur van de repository).

Het maken van release-branches is een andere eenvoudige bewerking voor het maken van branches. Net als functie-branches zijn release-branches gebaseerd op de develop-branch. Een nieuwe release-branch kan op de volgende manieren worden gemaakt:

Zonder de 'git-flow'-extensies:

1git checkout develop
2git checkout -b release/0.1.0

Met de 'git-flow'-extensies:

1$ git flow release start 0.1.0
2Switched to a new branch 'release/0.1.0'

Zodra de release klaar is om te verzenden, wordt deze samengevoegd in main en develop, waarna de release-branch wordt verwijderd. Het is belangrijk om weer samen te voegen in develop, omdat er mogelijk kritieke updates zijn toegevoegd aan de release-branch. Deze moeten toegankelijk zijn voor nieuwe functies. Als codebeoordeling belangrijk is in je organisatie, is dit een ideale plek voor een pull-aanvraag.

Gebruik de volgende methoden om een release-branch te voltooien:

Zonder de 'git-flow'-extensies:

1git checkout main
2git merge release/0.1.0

Of met de 'git-flow'-extensie:

1git flow release finish '0.1.0'

Hotfix-branches

Onderhouds- of 'hotfix'-branches worden gebruikt om snel productiereleases te patchen. Hotfix-branches lijken veel op release-branches en feature-branches, behalve dat ze gebaseerd zijn op main in plaats van develop. Dit is de enige branch die direct van main moet worden vertakt. Zodra de oplossing is voltooid, moet deze worden samengevoegd in zowel main als develop (of de huidige release-branch). Ook moet main worden getagd met een bijgewerkt versienummer.

Met een speciale ontwikkelingslijn voor bugfixes kan je team problemen oplossen zonder de rest van de workflow te onderbreken of te wachten op de volgende releasecyclus. Je kunt onderhoudsbranches zien als ad hoc release-branches die rechtstreeks aan main zijn gekoppeld. Een hotfix-branches kan op de volgende manieren worden gemaakt:

Zonder de 'git-flow'-extensies:

1git checkout main
2git checkout -b hotfix_branch

Met de 'git-flow'-extensies:

1$ git flow hotfix start hotfix_branch

Net als bij het voltooien van een release-branch wordt een hotfix-branch samengevoegd in zowel main  als develop.

1git checkout main
2git merge hotfix_branch
3git checkout develop
4git merge hotfix_branch
5git branch -D hotfix_branch

1$ git flow hotfix finish hotfix_branch

Voorbeeld

Hieronder volgt een compleet voorbeeld dat een proces voor functiebranches laat zien. Er wordt vanuit gegaan dat we een repo-opstelling hebben met een main-branch.

1git checkout main
2git checkout -b develop
3git checkout -b feature_branch
4# work happens on feature branch
5git checkout develop
6git merge feature_branch
7git checkout main
8git merge develop
9git branch -d feature_branch

Naast het functie- en release-proces is er een hotfix-voorbeeld:

1git checkout main
2git checkout -b hotfix_branch
3# work is done commits are added to the hotfix_branch
4git checkout develop
5git merge hotfix_branch
6git checkout main
7git merge hotfix_branch

Samenvatting

We hebben de Gitflow-workflow besproken. Gitflow is een van de vele soorten Git-workflows die jij en je team kunnen gebruiken.

Enkele belangrijke leerpunten die je over Gitflow moet weten, zijn:

• De workflow is geweldig voor een softwareworkflow op basis van releases;

• Gitflow biedt een speciaal kanaal voor hotfixes voor productie.

De Gitflow-workflow verloopt als volgt:

1. Er wordt een develop-branch gemaakt van main;

2. Er wordt een release-branch gemaakt van develop;

3. Er worden functie-branches  gemaakt van develop;

4. Wanneer een functie is voltooid, wordt deze samengevoegd in de develop-branch;

5. Wanneer de release-branch is voltooid, wordt deze samengevoegd met develop en main;

6. Wanneer er een probleem in main wordt gedetecteerd, wordt er een hotfix-branch gemaakt van main;

7. Zodra de hotfix is voltooid, wordt deze samengevoegd met zowel develop als main.

Lees vervolgens meer over de workflow voor vertakkingen of ga naar onze pagina voor het vergelijken van workflows.