Git-workflows vergelijken: wat je moet weten

Bij het evalueren van een workflow voor je team is het van het grootste belang dat je rekening houdt met de cultuur van je team. Je wilt dat de workflow de effectiviteit van je team vergroot en niet een last vormt die de productiviteit beperkt. Bij het evalueren van een Git-workflow moet je rekening houden met het volgende:

• Schaalt deze workflow mee met de grootte van het team?
• Is het gemakkelijk om vergissingen en fouten ongedaan te maken met deze workflow?
• Brengt deze workflow nieuwe, onnodige cognitieve overheadkosten met zich mee voor het team?

Ontwikkelaars beginnen met het klonen van de centrale repository. In hun eigen lokale kopieën van het project bewerken ze bestanden en committen ze wijzigingen door zoals ze zouden doen met SVN; deze nieuwe commits worden echter lokaal opgeslagen - ze zijn volledig geïsoleerd van de centrale repository. Hierdoor kunnen ontwikkelaars het synchroniseren upstream uitstellen tot ze op een geschikt breekpunt zijn.

Om wijzigingen in het officiële project te publiceren, 'pushen' ontwikkelaars hun lokale main-branch naar de centrale repository. Dit is het equivalent van svn commit, met dien verstande dat alle lokale commits worden opgeteld die nog niet in de centrale main-branch staan.

Zorg ervoor dat je een geldige SSH-gebruikersnaam gebruikt voor de gebruiker, het domein of het IP-adres van je server voor de host en de locatie waar je je repo wilt opslaan voor /path/to/repo.git. Merk op dat de extensie .git gewoonlijk wordt toegevoegd aan de naam van de repository om aan te geven dat het een bare repository is.

Vervolgens maakt elke ontwikkelaar een lokale kopie aan van het hele project. Dit wordt bereikt met de opdracht git clone:

Wanneer je een repository kloont, voegt Git automatisch een sneltoets toe, genaamd origin, die terugverwijst naar de 'bovenliggende' repository, in de veronderstelling dat je daar later in het traject mee wilt communiceren.

Onthoud dat, aangezien deze opdrachten lokale commits genereren, John dit proces net zo vaak kan herhalen als hij wil zonder zich zorgen te hoeven maken over wat er in de centrale repository gebeurt. Dit kan erg handig zijn voor grote functies die opgesplitst moeten worden in eenvoudigere, meer atomische brokken.

Deze opdracht pusht de nieuwe gecommitteerde wijzigingen naar de centrale repository. Bij het pushen van wijzigingen naar de centrale repository is het mogelijk dat er al eerder updates van een andere ontwikkelaar zijn gepusht die code bevatten die in strijd is met de beoogde push-updates. Git zal een bericht sturen waarin dit conflict wordt aangegeven. In deze situatie moet eerst git pull worden uitgevoerd. Dit conflictscenario wordt nader toegelicht in het volgende gedeelte.

Voordat de ontwikkelaar een functie kan publiceren, moet deze de bijgewerkte centrale commits ophalen en zijn of haar wijzigingen daarop rebaseren. Dit is hetzelfde als zeggen: „Ik wil mijn wijzigingen toevoegen aan wat John al heeft gedaan”. Het resultaat is een perfect lineaire geschiedenis, net als bij traditionele SVN-workflows.

Als lokale wijzigingen rechtstreeks in strijd zijn met upstream-commits, onderbreekt Git het rebaseringsproces en krijg je de kans om de conflicten handmatig oplossen. Het leuke van Git is dat het dezelfde opdrachten git status en git add gebruikt voor zowel het genereren van commits als het oplossen van samenvoegingsconflicten. Dit maakt het eenvoudig voor nieuwe ontwikkelaars om hun eigen samenvoegingen te beheren. En als ze zelf in de problemen komen, maakt Git het heel eenvoudig om de volledige rebase af te breken en het opnieuw te proberen (of hulp te zoeken).

In zijn lokale repository kan John functies ontwikkelen met behulp van het standaard Git-commit-proces: bewerken, stagen en committen.

Onthoud dat, aangezien deze opdrachten lokale commits genereren, John dit proces net zo vaak kan herhalen als hij wil zonder zich zorgen te hoeven maken over wat er in de centrale repository gebeurt.

Ondertussen werkt Mary aan haar eigen functie in haar eigen lokale repository, waarbij ze gebruik maakt van hetzelfde proces voor bewerken/stagen/committen. Net zoals voor John geldt, het maakt voor haar niet uit wat er in de centrale repository gebeurt, en het maakt haar echt niet uit wat John doet in zijn lokale repository, aangezien alle lokale repository's privé zijn.

Zodra John klaar is met zijn functie, moet hij zijn lokale commits publiceren in de centrale repository zodat andere teamleden er toegang tot hebben. Hij kan dit doen met de opdracht git push, bijvoorbeeld:

Onthoud dat origin de verbinding op afstand is met de centrale repository die Git heeft aangemaakt toen John die kloonde. Het main argument geeft bij Git aan dat de main-branch van de oorsprong eruit moet zien als zijn lokale main-branch. Aangezien de centrale repository niet is bijgewerkt sinds John deze heeft gekloond, zal dit geen conflicten veroorzaken en werkt de push zoals verwacht.

Laten we eens kijken wat er gebeurt als Mary haar functie probeert te pushen nadat John zijn wijzigingen in de centrale repository succesvol heeft gepubliceerd. Ze kan exact dezelfde push-opdracht gebruiken:

Maar aangezien haar lokale geschiedenis afwijkt van de centrale repository, weigert Git de aanvraag met een nogal uitgebreide foutmelding:

Dit voorkomt dat Mary officiële commits overschrijft. Ze moet de updates van John in haar repository opnemen, ze integreren met haar lokale wijzigingen en het dan opnieuw proberen.

Mary kan git pull gebruiken om upstream veranderingen in haar repository aan te brengen. Deze opdracht lijkt een beetje op svn-update: hij haalt de volledige geschiedenis van de upstream commit binnen in Mary's lokale repository en probeert die te integreren in haar lokale commits:

De optie --rebase geeft Git de opdracht om alle commits van Mary naar de tip van de main-branch te verplaatsen nadat deze zijn gesynchroniseerd met de wijzigingen uit de centrale repository, zoals hieronder weergegeven:

De pull zou nog steeds werken als je deze optie zou vergeten, maar je zou dan eindigen met een overbodige 'samenvoegingscommit' elke keer dat iemand moest synchroniseren met de centrale repository. Voor deze workflow is het altijd beter om te rebaseren in plaats van een merge commit te genereren.

Rebasing werkt door elke lokale commit één voor één over te dragen naar de vernieuwde main-branch. Dit betekent dat je samenvoegingsconflicten vastlegt op basis van commit-by-commit in plaats van ze allemaal op te lossen in één grote samenvoegingscommit. Dit zorgt ervoor dat je commits zo gefocust mogelijk blijven en zorgt voor een schone projectgeschiedenis. Dit maakt het op zijn beurt veel gemakkelijker om uit te zoeken waar bugs zijn geïntroduceerd en, indien nodig, om wijzigingen terug te draaien met minimale gevolgen voor het project.

Als Mary en John aan functies werken die niets met elkaar te maken hebben, is het onwaarschijnlijk dat het rebaseringsproces tot conflicten zal leiden. Maar als dat wel gebeurt, pauzeert Git de rebase bij de huidige commit en wordt het volgende bericht weergegeven, samen met enkele relevante instructies:

Het mooie van Git is dat iedereen zijn eigen samenvoegingsconflicten kan oplossen. In ons voorbeeld zou Mary gewoon een git-status uitvoeren om te zien waar het probleem zit. Conflicterende bestanden worden weergegeven in het gedeelte Niet-samengevoegde paden:

Daarna kan ze het bestand of de bestanden naar eigen inzicht bewerken. Zodra ze tevreden is met het resultaat, kan ze de bestanden op de gebruikelijke manier stagen en git-tebase de rest laten doen:

En dat is alles wat nodig is. Git gaat verder met de volgende commit en herhaalt het proces voor alle andere commits die tot conflicten leiden.

Als je zover komt en je beseft dat je geen idee hebt wat er aan de hand is, raak dan niet in paniek. Voer gewoon de volgende opdracht uit en je bent meteen terug waar je begon:

Wanneer ze klaar is met de synchronisatie met de centrale repository, kan Mary haar wijzigingen publiceren:

Zoals je ziet, is het mogelijk om een traditionele Subversion-ontwikkelomgeving te repliceren met slechts een handvol Git-opdrachten. Dit is geweldig om teams van SVN af te krijgen, maar het maakt geen gebruik van het gedistribueerde karakter van Git.

De gecentraliseerde workflow is geweldig voor kleine teams. Het hierboven beschreven proces voor het oplossen van conflicten kan een knelpunt vormen naarmate je team groter wordt. Als je team vertrouwd is met de gecentraliseerde workflow, maar de samenwerkingsinspanningen wil stroomlijnen, is het zeker de moeite waard om de voordelen van de Workflow feature-branches te verkennen. Door aan elke functie een afzonderlijke branch te wijden, is het mogelijk om diepgaande discussies op gang te brengen over nieuwe toevoegingen voordat ze worden geïntegreerd in het officiële project.

De gecentraliseerde workflow is in wezen een bouwsteen voor andere Git-workflows. De meeste populaire Git-workflows hebben een soort gecentraliseerde repo die individuele ontwikkelaars kunnen pushen en pullen. Hieronder bespreken we kort een paar andere populaire Git-workflows. Deze uitgebreide workflows bieden meer gespecialiseerde patronen om branches te beheren voor de ontwikkeling van functies, hotfixes en de uiteindelijke release.

Feature-branches zijn een logische uitbreiding van een gecentraliseerde workflow. Het kernidee achter de Workflow feature-branches is dat alle ontwikkeling van functies moet plaatsvinden in een speciale branch in plaats van in de main-branch. Deze inkapseling maakt het eenvoudig om meerdere ontwikkelaars aan een bepaalde functie te laten werken zonder de hoofdcodebase te verstoren. Het betekent ook dat de main-branch nooit beschadigde code mag bevatten, wat een groot voordeel is voor omgevingen met continue integratie.

De Workflow Gitflow is voor het eerst gepubliceerd in een zeer gewaardeerde blogpost uit 2010 van Vincent Driessen op nvie. De workflow Gitflow definieert een strikt branchingmodel dat is ontworpen rond de projectrelease. Deze workflow voegt geen nieuwe concepten of opdrachten toe die verder gaan dan wat nodig is voor de Workflow feature-branches. In plaats daarvan kent de workflow zeer specifieke rollen toe aan verschillende branches en definieert hij hoe en wanneer deze moeten communiceren.

De Workflow Vertakking is fundamenteel anders dan de andere workflows die in deze tutorial worden besproken. Forking (vertakken) geeft elke ontwikkelaar een repository aan de serverkant in plaats van dat één repository aan de serverkant wordt gebruikt als de 'centrale' codebase. Elke medewerker heeft dus niet één, maar twee Git-repository's: een lokale (privé) en een aan een openbare serverkant.

Er is niet één Git-workflow die voor alles en iedereen geschikt is. Zoals eerder vermeld, is het belangrijk om een Git-workflow te ontwikkelen die de productiviteit van je team verhoogt. Naast de teamcultuur moet een workflow ook een aanvulling zijn op de bedrijfscultuur. Git-functies zoals branches en tags zouden een aanvulling moeten zijn op het releaseschema van je bedrijf. Als je team software voor projectmanagement gebruikt om taken bij te houden, wil je misschien branches gebruiken die overeenkomen met lopende taken. Daarnaast zijn er enkele richtlijnen waarmee je rekening moet houden bij het kiezen van een workflow:

Het is belangrijk om een workflow te hebben die proactief helpt om samenvoegingen te voorkomen die moeten worden teruggedraaid. Een voorbeeld hiervan is een workflow waarbij een branch wordt getest voordat deze kan worden samengevoegd met de main-branch. Ongelukken gebeuren echter wel degelijk. Dat gezegd hebbende, is het nuttig om een workflow te hebben die het mogelijk maakt om dingen terug te draaien zonder de flow voor andere teamleden te verstoren.

Een workflow moet een aanvulling zijn op de releasecyclus voor softwareontwikkeling van je bedrijf. Als je van plan bent om meerdere keren per dag een release uit te brengen, dan wil je dat je main-branch stabiel blijft. Als je releaseschema minder frequent is, kun je overwegen om Git-tags te gebruiken om een branch naar een versie te taggen.

In dit document hebben we de Git-workflows besproken. We hebben uitgebreid gekeken naar een gecentraliseerde workflow met praktische voorbeelden. Voortbouwend op de gecentraliseerde workflow bespraken we aanvullende gespecialiseerde workflows. Enkele belangrijke opmerkingen uit dit document zijn:

• Er is niet één Git-workflow die voor alles en iedereen geschikt is
• Een workflow moet eenvoudig zijn en de productiviteit van je team vergroten
• De vereisten van je bedrijf moeten je Git-workflow helpen vormgeven

Bekijk ons uitgebreide overzicht van de Workflow feature-branche voor meer informatie over de volgende Git-workflow.