5 Git workflows en branching strategie die je kunt gebruiken om je ontwikkelproces te verbeteren
Ik heb nog geen ontwikkelaar ontmoet die naar een conflictmelding keek en niet aan zijn haren trok van frustratie.
Proberen om elk merge conflict op te lossen is een van die dingen waar elke ontwikkelaar een hekel aan heeft. Vooral als het je overkomt als je je klaarmaakt voor een productie deploy!
Dit is waar het hebben van de juiste Git workflow een wereld van goeds kan doen voor je ontwikkel workflow.
Natuurlijk zal het hebben van de juiste Git workflow niet al je problemen oplossen. Maar het is wel een stap in de goede richting. Immers, met elk team dat op afstand werkt, is de noodzaak om samen features te bouwen zonder dat je codebase verstoord raakt van cruciaal belang.
Hoe je het opzet hangt af van het project waar je aan werkt, de releaseschema’s die je team heeft, de grootte van het team, en nog veel meer.
In dit artikel lopen we met je door 5 verschillende git workflows, hun voordelen, hun nadelen, en wanneer je ze zou moeten gebruiken. Laten we beginnen!
Basic Git Workflow
De meest basale git workflow is die waar er maar één branch is – de master branch. Ontwikkelaars committen direct in deze branch en gebruiken deze om te deployen naar de staging en productie omgeving.
Deze workflow wordt meestal niet aangeraden, tenzij je aan een zijproject werkt en snel aan de slag wilt.
Omdat er maar één tak is, is er hier eigenlijk geen proces. Dit maakt het moeiteloos om met Git aan de slag te gaan. Echter, een aantal nadelen waar je rekening mee moet houden als je deze werkwijze gebruikt zijn:
- Samenwerken aan code zal leiden tot meerdere conflicten.
- Kans op het verschepen van buggy software naar productie is groter.
- Het onderhouden van schone code is moeilijker.
Git Feature Branch Workflow
De Git Feature Branch workflow wordt een must als je meer dan één ontwikkelaar hebt die aan dezelfde codebase werkt.
Stel je voor dat je één ontwikkelaar hebt die aan een nieuwe feature werkt. En een andere ontwikkelaar die werkt aan een tweede functie. Als beide ontwikkelaars in dezelfde branch werken en daar commits aan toevoegen, zou dat van de codebase een enorme puinhoop maken met veel conflicten.
Om dit te voorkomen, kunnen de twee ontwikkelaars twee aparte branches van de master branch maken en afzonderlijk aan hun features werken. Als ze klaar zijn met hun feature, kunnen ze hun respectievelijke branch samenvoegen met de master branch, en deployen zonder te hoeven wachten tot de tweede feature klaar is.
De voordelen van het gebruik van deze workflow is, dat de git feature branch workflow je toestaat om samen te werken aan code zonder dat je je zorgen hoeft te maken over code conflicten.
Git Feature Workflow met Develop Branch
Deze workflow is een van de meer populaire workflows onder ontwikkelaar teams. Het is vergelijkbaar met de Git Feature Branch workflow met een develop branch die parallel aan de master branch wordt toegevoegd.
In deze workflow weerspiegelt de master branch altijd een productieklare staat. Als het team wil deployen naar productie, deployen ze dat vanaf de master branch.
De develop branch reflecteert de status met de laatste ontwikkel wijzigingen voor de volgende release. Ontwikkelaars maken branches van de ontwikkel branch en werken aan nieuwe functies. Als de ontwikkeling klaar is, wordt het getest, samengevoegd met de ontwikkel tak, getest met de code van de ontwikkel tak in het geval dat er een eerdere samenvoeging is geweest, en dan samengevoegd met master.
Het voordeel van deze workflow is dat het teams in staat stelt om consistent nieuwe features samen te voegen, ze te testen in staging, en ze uit te rollen naar productie. Hoewel het onderhouden van code makkelijker is, kan het voor sommige teams een beetje vermoeiend worden, omdat het kan voelen als het doorlopen van een vervelend proces.
Gitflow Workflow
De gitflow workflow lijkt erg op de vorige workflow die we besproken hebben, gecombineerd met twee andere branches – de release branch en de hot-fix branch.
De hot-fix branch
De hot-fix branch is de enige branch die gemaakt wordt van de master branch en direct gemerged wordt naar de master branch in plaats van de develop branch. Het wordt alleen gebruikt als je snel een patch moet maken voor een productie probleem. Een voordeel van deze branch is, dat het je in staat stelt om snel een productie probleem uit te rollen zonder de werkstroom van anderen te verstoren of zonder te hoeven wachten op de volgende release cyclus.
Als de fix eenmaal is samengevoegd in de master branch en uitgerold, zou het samengevoegd moeten worden in zowel de develop als de huidige release branch. Dit wordt gedaan om er zeker van te zijn dat iedereen die forkt van develop om een nieuwe feature branch te maken, de laatste code heeft.
De release branch
De release branch wordt gevorkt van de develop branch nadat de develop branch alle features gepland voor de release er succesvol in heeft samengevoegd.
Geen code gerelateerd aan nieuwe features wordt toegevoegd aan de release branch. Alleen code die betrekking heeft op de release wordt toegevoegd aan de release branch. Bijvoorbeeld, documentatie, bug fixes, en andere taken gerelateerd aan deze release worden toegevoegd aan deze branch.
Als deze branch is samengevoegd met master en uitgerold naar productie, wordt het ook weer samengevoegd in de develop branch, zodat wanneer een nieuwe functie wordt gevorkt van develop, het de nieuwste code heeft.
Deze workflow werd voor het eerst gepubliceerd en populair gemaakt door Vincent Driessen en wordt sindsdien veel gebruikt door organisaties die een geplande releasecyclus hebben.
Omdat de git-flow een wrapper rond Git is, kun je git-flow in je huidige repository installeren. Het is een eenvoudig proces en het verandert niets in je repository, behalve dat het branches voor je aanmaakt.
Om op een Mac machine te installeren, voer je brew install git-flow uit in je terminal.
Om op een Windows machine te installeren, moet je git-flow downloaden en installeren. Nadat de installatie klaar is, voer je het volgende Git Command uit git flow init om het in je project te gebruiken.
Git Fork Workflow
De Fork workflow is populair onder teams die open-source software gebruiken.
De flow ziet er meestal als volgt uit:
- De ontwikkelaar forkt de officiële repository van de open-source software. Een kopie van deze repository wordt gemaakt in hun account.
- De ontwikkelaar cloned vervolgens de repository van hun account naar hun lokale systeem.
- Een remote pad voor de officiële repository wordt toegevoegd aan de repository die is gekloond naar het lokale systeem.
- De ontwikkelaar maakt een nieuwe feature branch aan in hun lokale systeem, maakt wijzigingen, en commit ze.
- Deze wijzigingen worden samen met de branch gepushed naar de ontwikkelaar zijn kopie van de repository op zijn account.
- Een pull request van de branch wordt geopend naar de officiële repository.
- De manager van de officiële repository controleert de wijzigingen en keurt de wijzigingen goed om samengevoegd te worden in de officiële repository.
Het automatiseren van je Git Workflows en Branching Strategie voor een betere productiviteit
Eén van de dingen waar ontwikkelaars constant mee moeten jongleren is het updaten van hun project management tool om hun teamgenoten op de hoogte te houden. Daarom automatiseren onze ontwikkelaars bij Zepel hun workflow, zodat ze meer van hun tijd kunnen besteden aan het bouwen van de software.
Hier zie je hoe we onze git-workflow automatiseren, zodat iedereen op de hoogte blijft:
Hoewel Zepel diep integreert met GitHub, Bitbucket en GitLab, gebruiken wij GitHub intern. Dus zodra we GitHub hebben geïntegreerd met Zepel, stelt ons ontwikkelingsteam de git-workflowautomatisering binnen Zepel in. Dit is hoe het er vandaag uitziet:
Als ontwikkelaars vooruitgang blijven boeken, krijgt ons team automatisch een Slack-notificatie en worden hun wijzigingen vastgelegd in de user story.
Jouw eigen workflow en Git branching strategie!
De Git workflows die ik in dit artikel heb laten zien zijn voorbeelden van enkele van de populaire en best werkende workflows voor het ontwikkelteam. Sommige teams maken een branch voor Staging en het werkt perfect voor hen.
Als je andere workflows gebruikt die goed voor je werken, tweet ze naar ons @getzepel. We laten ze graag zien!
Hulpvolle Artikelen
Vikash KoushikThe Zepel Blog 
Ranjali RoyThe Zepel Blog 
Ranjali RoyThe Zepel Blog 