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-methode continue 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 hij zeer specifieke rollen toe aan verschillende branches en definieert hij hoe en wanneer deze moeten communiceren. Naast functie-branches maakt het gebruik van afzonderlijke branches voor het voorbereiden, onderhouden en opnemen van releases. Natuurlijk kun je ook gebruikmaken van alle voordelen van de functie-branch-workflow: pull-verzoeken, geïsoleerde experimenten en efficiëntere samenwerking.

Aan de slag

Gitflow is eigenlijk gewoon een abstract idee van een Git-workflow. Dit betekent dat het voorschrijft welk soort branches moeten worden opgezet en hoe ze moeten worden samengevoegd. We zullen hieronder ingaan op de doeleinden van de branches. De toolset git-flow is een echt opdrachtregelprogramma met een installatieproces. Het installatieproces voor git-flow is eenvoudig. Pakketten voor git-flow zijn beschikbaar op meerdere besturingssystemen. Op OSX-systemen kun je brew install git-flow uitvoeren. In Windows moet je git-flow downloaden en installeren. Na het installeren van git-flow kun je het in je project gebruiken door git flow init uit te voeren. Git-flow is een schil om Git. De opdracht git flow init is een extensie van de standaard git init-opdracht en verandert niets in je repository. Er worden alleen branches voor je gemaakt.

Hoe het werkt

Git flow-workflow - Historische branches

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:

git branch develop
git 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:

$ git flow init


Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []


$ git branch
* develop
 main

Functie-branches

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-branches develop als hun bovenliggende branch. Wanneer een functie is voltooid, wordt deze weer samengevoegd in 'develop'. Functies mogen nooit rechtstreeks communiceren met main.

Git flow-workflow - Functie-branches

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:

git checkout develop
git checkout -b feature_branch

Met de 'git-flow'-extensie:

git 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:

git checkout develop
git merge feature_branch

Met de 'git-flow'-extensies:

git flow feature finish feature_branch

Release-branches

Git flow-workflow - 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 branche 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:

git checkout develop
git checkout -b release/0.1.0

Met de 'git-flow'-extensies:

$ git flow release start 0.1.0
Switched 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 je organisatie codebeoordeling belangrijk vindt, is dit een ideale plek voor een pull-verzoek.

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

Zonder de 'git-flow'-extensies:

git checkout main
git merge release/0.1.0

Of met de 'git-flow'-extensie:

git flow release finish '0.1.0'

Hotfix-branches

Git flow-workflow - 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 probleemoplossingen 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:

git checkout main
git checkout -b hotfix_branch

Met de 'git-flow'-extensies:

$ 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.

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
$ git flow hotfix finish hotfix_branch

Voorbeeld

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

git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch

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

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git 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.

Klaar om Git te leren?

Probeer deze interactieve tutorial.

Nu aan de slag