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.
gerelateerd materiaal
Uitgebreid Git log
Oplossing bekijken
Git leren met Bitbucket Cloud
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:
git branch develop
git push -u origin developDeze 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
mainFunctie-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-branches develop 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:
git checkout develop
git checkout -b feature_branchMet de 'git-flow'-extensie:
git flow feature start feature_branchGa 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_branchMet de 'git-flow'-extensies:
git flow feature finish feature_branchRelease-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.0Met 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.0Of met de 'git-flow'-extensie:
git 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 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_branchMet de 'git-flow'-extensies:
$ git flow hotfix start hotfix_branchNet 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_branchVoorbeeld
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_branchNaast 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_branchSamenvatting
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.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
Bitbucket-blog
DevOps-leertraject
