Git-workflow voor functie-branches
Het kernidee achter de workflow voor functie-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 bevat, wat een groot voordeel is voor omgevingen met continue integratie.
Door de ontwikkeling van functies is het ook mogelijk om gebruik te maken van pull-aanvragen, een manier om discussies in een branch op gang te brengen. Deze bieden andere ontwikkelaars de mogelijkheid om een functie goed te keuren voordat deze in het officiële project wordt geïntegreerd. Of als je midden in een functie vast komt te zitten, kun je een pull-aanvraag openen waarin je collega's om suggesties kunt vragen. Het punt is dat je team met pull-aanvragen heel eenvoudig commentaar kan geven op elkaars werk.
De Git-workflow voor functie-branches is een samen te stellen workflow die op hoog niveau gebruikt kan worden door andere Git-workflows. We hebben andere Git-workflows besproken op de overzichtspagina van de Git-workflow. De Git-workflow voor functie-branches is gericht op branchingmodellen, wat betekent dat het een leidraad is voor het beheren en aanmaken van branches. Andere workflows zijn meer gericht op repo. De Git-workflow voor functie-branches kan in andere workflows geïntegreerd worden. De Gitflow en Git-vertakkingsworkflows gebruiken van oorsprong een Git-workflow voor functie-branches met betrekking tot hun branchingmodellen.
Hoe het werkt
De workflow voor functie-branch gaat uit van een centrale repository, en de main-branch vertegenwoordigt de officiële projectgeschiedenis. In plaats van zich rechtstreeks op hun lokale main-branch te richten, maken ontwikkelaars elke keer een nieuwe branch aan wanneer ze aan een nieuwe functie beginnen te werken. De belangrijkste branches moeten een beschrijvende naam hebben, bijvoorbeeld geanimeerde-menu-items of issue-#1061. Het idee is om elke branch een duidelijk, zeer gericht doel te geven. Git maakt technisch gezien geen onderscheid tussen de main-branch en functie-branches, zodat ontwikkelaars een functie-branch kunnen bewerken, stagen en er wijzigingen in kunnen doorvoeren.
Bovendien kunnen (en moeten) functie-branches naar de centrale repository worden verplaatst. Op die manier is het mogelijk om een functie te delen met andere ontwikkelaars zonder de officiële code te beïnvloeden. Aangezien main de enige 'speciale' branch is, levert het opslaan van meerdere functie-branches in de centrale repository geen problemen op. Natuurlijk is dit ook een handige manier om een back-up te maken van ieders lokale commits. Wat nu volgt is een overzicht van de levenscyclus van een functie-branch.
Begin bij de main-branch
Alle functie-branches worden gemaakt op basis van de meest recente codestatus van een project. In deze handleiding wordt ervan uitgegaan dat dit wordt onderhouden en bijgewerkt in de main-branch.
gerelateerd materiaal
Uitgebreid Git log
Oplossing bekijken
Git leren met Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainDe repository aanmaken
Hiermee wordt de repo overgezet naar de main-branch, worden de laatste commits opgevraagd en wordt het lokale exemplaar van de main in de repo teruggezet zodat deze overeenkomt met de nieuwste versie.
Een new-branch aanmaken
Gebruik een aparte branch voor elke functie of issue waaraan je werkt. Nadat je een branch hebt aangemaakt, moet je die lokaal uitchecken zodat alle wijzigingen worden aangebracht in die branch.
git checkout -b new-featureDit checkt een branch met de naam new-feature uit op basis van main, en de -b-markering geeft Git de opdracht om de branch aan te maken als die nog niet bestaat.
Wijzigingen bijwerken, toevoegen, committen en pushen
In deze branch kun je op de gebruikelijke manier wijzigingen bewerken, stagen en committen, waardoor de functie met zoveel mogelijk nodige commits opgebouwd wordt. Werk aan de functie en maak commits zoals je dat altijd doet wanneer je Git gebruikt. Als je klaar bent, kun je je commits pushen om de functie-branch in Bitbucket bij te werken.
git status
git add <some-file>
git commitFunctie-branch naar een externe plek pushen
Het is een goed idee om de functie-branch naar de centrale repository te pushen. Dit is een handige back-up: wanneer er wordt samengewerkt met andere ontwikkelaars geeft dit hen toegang om de commits voor de nieuwe branch te bekijken.
git push -u origin new-featureDeze opdracht pusht een nieuwe functie naar de centrale repository (origin), en de -u-markering voegt deze toe als een branch voor tracering op afstand. Nadat de branch voor tracering is ingesteld, kan git push zonder parameters worden opgeroepen om de branch new-feature automatisch naar de centrale repository te sturen. Om feedback te krijgen over de nieuwe functie-branch, moet je een pull-aanvraag aanmaken in een repositorybeheeroplossing als Bitbucket Cloud of Bitbucket Data Center. Van daaruit kun je beoordelaars toevoegen en ervoor zorgen dat alles in orde is voordat je gaat samenvoegen.
Feedback verwerken
Nu geven teamgenoten opmerkingen en goedkeuring voor de gepushte commits. Verwerk hun opmerkingen lokaal, voer wijzigingen door en push de voorgestelde wijzigingen naar Bitbucket. Je updates verschijnen in de pull-aanvraag.
Je pull-aanvragen samenvoegen
Voordat je gaat samenvoegen, moet je mogelijk samenvoegingsconflicten oplossen als anderen wijzigingen hebben aangebracht in de repo. Als je pull-aanvraag is goedgekeurd en conflictvrij is, kun je je code toevoegen aan de main-branch. Voeg je code samen vanuit de pull-aanvraag in Bitbucket.
Pull-aanvragen
Naast het isoleren van de ontwikkeling van functies, kun je met branches wijzigingen bespreken via pull-aanvragen. Zodra iemand een functie heeft voltooid, wordt die niet meteen samengevoegd in de main. In plaats daarvan sturen ze de functie-branch naar de centrale server en dienen ze een pull-aanvraag in met de vraag om hun toevoegingen samen te voegen in de main. Hierdoor krijgen andere ontwikkelaars de mogelijkheid om de wijzigingen te bekijken voordat ze deel gaan uitmaken van de hoofdcodebase.
Codebeoordeling is een groot voordeel van pull-aanvragen, maar ze zijn in feite ontworpen als algemene manier om over code te praten. Je kunt pull-aanvragen zien als een discussie over een bepaalde branch. Dit betekent dat ze ook veel eerder in het ontwikkelingsproces kunnen worden gebruikt. Als een ontwikkelaar bijvoorbeeld hulp nodig heeft met een bepaalde functie, hoeft hij alleen maar een pull-aanvraag in te dienen. Belanghebbenden worden automatisch op de hoogte gebracht en kunnen de vraag direct naast de relevante commits zien.
Zodra een pull-aanvraag geaccepteerd is, is het publiceren van een functie vrijwel hetzelfde als in de gecentraliseerde workflow. Eerst moet je ervoor zorgen dat je lokale main gesynchroniseerd is met de stroomopwaartse main. Vervolgens voeg je de functie-branch samen in main en push je de bijgewerkte main terug naar de centrale repository.
Pull requests kunnen gefaciliteerd worden met oplossingen voor broncodebeheer, zoals Bitbucket Cloud.
Voorbeeld
Er volgt een voorbeeld van het soort scenario waarin een workflow voor functie-branches wordt gebruikt. Het scenario: een team beoordeelt de code voor een pull-aanvraag over een nieuwe functie. Dit is een voorbeeld van een van de vele doeleinden waarvoor dit model kan worden gebruikt.
Mary ontwikkelt een nieuwe functie
Voordat ze begint met de ontwikkeling van een functie heeft Mary een aparte branch nodig om aan te werken. Ze kan een nieuwe branch aanvragen met de volgende opdracht:
git checkout -b marys-feature mainDit checkt een branch genaamd marys-feature uit, gebaseerd op main, en de -b-markering geeft Git de opdracht om de branch aan te maken als die nog niet bestaat. In deze branch kan Mary op de gebruikelijke manier wijzigingen bewerken, stagen en committen, waardoor haar functie met zoveel mogelijk nodige commits opgebouwd wordt:
git status
git add <some-file>
git commitMary gaat lunchen
.svg?cdnVersion=2441)
In de loop van de ochtend voegt Mary een paar commits toe aan haar functie. Voordat ze gaat lunchen, is het een goed idee om haar functie-branch naar de centrale repository te verplaatsen. Dit is een handige back-up, maar als Mary zou samenwerken met andere ontwikkelaars, zou dat hen ook toegang geven tot haar oorspronkelijke commits.
git push -u origin marys-featureDeze opdracht pusht marys-feature naar de centrale repository (origin), en de -u-markering voegt deze toe als een branch voor tracering op afstand. Nadat Mary de trackingbranch heeft ingesteld, kan ze git push gebruiken zonder parameters om haar functie te pushen.
Mary maakt haar functie af
Als Mary terugkomt van de lunch, maakt ze haar functie af. Voordat ze alles samenvoegt in de main, moet ze een pull-aanvraag indienen om de rest van het team te laten weten dat ze klaar is. Maar eerst moet ze ervoor zorgen dat de centrale repository haar meest recente commits bevat:
git pushVervolgens dient ze de pull-aanvraag in haar Git GUI in met de vraag om marys-feature samen te voegen in de main, waarna teamleden automatisch op de hoogte worden gebracht. Het mooie van pull-aanvragen is dat ze reacties direct naast hun gerelateerde commits tonen. Zo is het eenvoudig om vragen te stellen over specifieke changesets.
Bill ontvangt de pull-aanvraag
.svg?cdnVersion=2441)
Bill krijgt de pull-aanvraag en bekijkt marys-feature. Hij besluit dat hij een paar wijzigingen wil aanbrengen voordat hij het in het officiële project integreert, en hij en Mary communiceren via de pull-aanvraag.
Mary brengt de wijzigingen aan
.svg?cdnVersion=2441)
Om de wijzigingen aan te brengen, gebruikt Mary precies hetzelfde proces als ze deed om de eerste iteratie van haar functie te maken. Ze bewerkt, staget, commits en pusht updates naar de centrale repository. Al haar activiteiten worden weergegeven in de pull-aanvraag en Bill kan ondertussen nog steeds opmerkingen maken.
Als hij dat zou willen, had Bill marys-feature naar zijn plaatselijke repository kunnen overzetten en er zelf aan kunnen werken. Alle commits die hij zou toevoegen, zouden ook in de pull-aanvraag verschijnen.
Mary publiceert haar functie
Zodra Bill klaar is om de pull-aanvraag te accepteren, moet iemand de functie samenvoegen in het stabiele project (dit kan zowel door Bill als door Mary worden gedaan):
git checkout main
git pull
git pull origin marys-feature
git pushDit proces leidt vaak tot een samenvoeging. Sommige ontwikkelaars vinden dit leuk omdat het een symbolische combinatie is van de functie met de rest van de codebase. Maar als je een voorliefde hebt voor een lineaire geschiedenis, is het mogelijk om de functie op het uiterste van de main te baseren voordat de samenvoeging wordt uitgevoerd, wat leidt tot een snelle samenvoeging.
Sommige GUI's automatiseren het proces voor acceptatie van pull-aanvragen door al deze opdrachten uit te voeren door op de knop Accepteren te klikken. Als dat bij jou niet het geval is, zou het in ieder geval de pull-aanvraag automatisch moeten kunnen sluiten wanneer de functie-branch wordt samengevoegd tot main.
Ondertussen doet John precies hetzelfde.
Terwijl Mary en Bill bezig zijn met marys-feature en erover praten in haar pull-aanvraag, doet John precies hetzelfde met zijn eigen functie-branch. Door functies in verschillende branches te isoleren, kan iedereen onafhankelijk werken, maar het is nog steeds belangrijk om wijzigingen met andere ontwikkelaars te delen als dat nodig is.
Samenvatting
In dit document hebben we de Git-workflow voor functie-branch besproken. Deze workflow helpt bij het organiseren en volgen van branches die gericht zijn op functiesets in het bedrijfsdomein. Andere Git-workflows, zoals de Git-vertakkingsworkflow en de Gitflow-workflow, zijn gericht op repo en kunnen gebruikmaken van de Git-workflow voor functie-branches om hun branching-modellen te beheren. In dit document zag je een codevoorbeeld op hoog niveau en een fictief voorbeeld van de implementatie van de Git functie-branch. Een paar belangrijke verbanden die je moet leggen met de workflow voor functie-branches zijn:
- is gericht op vertakkingspatronen
- kan gebruikt worden door andere op repo georiënteerde workflows
- bevordert de samenwerking met teamleden door middel van pull-aanvragen en het samenvoegen van beoordelingen
Het gebruik van git rebase tijdens de revisie en samenvoeging van een functie-branch zorgt voor een samenhangende Git-geschiedenis van samenvoegingen van functies. Een model voor functie-branches is een geweldige tool om samenwerking binnen een teamomgeving te bevorderen.
Klik verder in de Git-workflows en lees onze uitgebreide handleiding over de Gitflow-workflow.
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
