Een Git-vertakkingsstrategie aannemen

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Gedistribueerde versiebeheersystemen zoals Git bieden u flexibiliteit in het gebruik van versiebeheer om code te delen en te beheren. Uw team moet een balans vinden tussen deze flexibiliteit en de noodzaak om op een consistente manier samen te werken en code te delen.

Teamleden publiceren, delen, beoordelen en herhalen codewijzigingen via Git-vertakkingen die met anderen worden gedeeld. Stel een vertakkingsstrategie in voor uw team. U kunt beter samenwerken en minder tijd besteden aan het beheren van versiebeheer en meer tijd aan het ontwikkelen van code.

De volgende vertakkingsstrategieën zijn gebaseerd op de manier waarop we Git hier bij Microsoft gebruiken. Zie Hoe we Git gebruiken bij Microsoft voor meer informatie.

Houd uw vertakkingsstrategie eenvoudig

Houd uw vertakkingsstrategie eenvoudig. Bouw uw strategie op basis van deze drie concepten:

• Functievertakkingen gebruiken voor alle nieuwe functies en oplossingen voor fouten.
• Voeg functietakken samen in de hoofdbranch met behulp van pull-aanvragen.
• Houd een hoogwaardige, up-to-date hoofdvertakking.

Een strategie die deze concepten uitbreidt en tegenstrijdigheden vermijdt, leidt tot een werkstroom voor versiebeheer voor uw team die consistent en eenvoudig te volgen is.

Functiebranches gebruiken voor uw werk

Ontwikkel uw functies en los bugs op in functievertakkingen die zijn gebaseerd op uw hoofdvertakking. Deze vertakkingen worden ook wel onderwerptakken genoemd. Functiebranches isoleren werk dat wordt uitgevoerd van het voltooide werk in de hoofdbranch. Git-vertakkingen zijn goedkoop om te maken en te onderhouden. Zelfs kleine oplossingen en wijzigingen moeten hun eigen functiebranch hebben.

Het maken van functievertakkingen voor al uw wijzigingen maakt het controleren van de geschiedenis eenvoudig. Bekijk de doorvoeringen in de vertakking en bekijk de pull-aanvraag waarmee de vertakking is samengevoegd.

Geef uw functie-vertakkingen een naam volgens conventie

Gebruik een consistente naamconventie voor uw functievertakkingen om het werk te identificeren dat in de vertakking is uitgevoerd. U kunt ook andere informatie opnemen in de naam van de vertakking, zoals wie de vertakking heeft gemaakt.

Enkele suggesties voor het benoemen van uw functievertakkingen:

• gebruikers/gebruikersnaam/beschrijving
• gebruikers/gebruikersnaam/workitem
• bugfix/description
• functie/functienaam
• functie/functiegebied/functienaam
• hotfix/beschrijving

Notitie

Zie Vertakkingsmappen vereisen voor informatie over het instellen van beleid voor het afdwingen van een strategie voor vertakkingen.

Functievlagmen gebruiken om langlopende vertakkingen te beheren

Meer informatie over het gebruik van functievlagmen in uw code.

Code controleren en samenvoegen met pull-aanvragen

De beoordeling die plaatsvindt in een pull-aanvraag is essentieel voor het verbeteren van de codekwaliteit. Alleen vertakkingen samenvoegen via pull-aanvragen die uw beoordelingsproces doorgeven. Vermijd het samenvoegen van vertakkingen naar de hoofdbranch zonder een pull-aanvraag.

Het duurt even voordat beoordelingen in pull-aanvragen zijn voltooid. Uw team moet ermee instemmen wat er wordt verwacht van makers en revisoren van pull-aanvragen. Verantwoordelijkheden van revisoren distribueren om ideeën over uw team te delen en kennis van uw codebase te verspreiden.

Enkele suggesties voor geslaagde pull-aanvragen:

• Twee revisoren zijn een optimaal aantal op basis van onderzoek.
• Als uw team al een codebeoordelingsproces heeft, brengt u pull-aanvragen mee naar wat u al doet.
• Zorg ervoor dat dezelfde revisoren worden toegewezen aan een groot aantal pull-aanvragen. Pull-aanvragen werken beter wanneer revisoren verantwoordelijkheden worden gedeeld in het team.
• Geef voldoende details in de beschrijving om revisoren snel op de hoogte te brengen van uw wijzigingen.
• Voeg een build- of gekoppelde versie van uw wijzigingen toe die worden uitgevoerd in een gefaseerde omgeving met uw pull-aanvraag. Anderen kunnen de wijzigingen eenvoudig testen.

Een hoogwaardige, up-to-date hoofdvertakking behouden

De code in uw hoofdbranch moet tests doorgeven, schoon bouwen en altijd actueel zijn. Uw hoofdbranch heeft deze kwaliteiten nodig, zodat functietakken die door uw team zijn gemaakt, beginnen met een bekende goede versie van code.

Stel een vertakkingsbeleid in voor uw hoofdbranch die:

• Vereist een pull-aanvraag om code samen te voegen. Deze aanpak voorkomt directe pushes naar de hoofdbranch en zorgt voor discussie over voorgestelde wijzigingen.
• Voegt automatisch revisoren toe wanneer een pull-aanvraag wordt gemaakt. De toegevoegde teamleden controleren de code en reageren op de wijzigingen in de pull-aanvraag.
• Vereist een geslaagde build om een pull-aanvraag te voltooien. Code die is samengevoegd in de hoofdbranch, moet op een schone manier worden gebouwd.

Tip

De build-pijplijn voor uw pull-aanvragen moet snel zijn voltooid, dus dit heeft geen invloed op het beoordelingsproces.

Releases beheren

Gebruik releasebranches om wijzigingen in een release van uw code te coördineren en te stabiliseren. Deze vertakking duurt lang en wordt niet weer samengevoegd in de hoofdvertakking in een pull-aanvraag, in tegenstelling tot de functievertakkingen. Maak zoveel release-vertakkingen als u nodig hebt. Houd er rekening mee dat elke actieve releasebranch een andere versie van de code vertegenwoordigt die u moet ondersteunen. Vergrendelingsreleasevertakkingen wanneer u klaar bent om te stoppen met het ondersteunen van een bepaalde release.

Releasebranches gebruiken

Maak een releasebranch vanuit de hoofdbranch wanneer u dicht bij de release of een andere mijlpaal komt, zoals het einde van een sprint. Geef deze vertakking een duidelijke naam die deze aan de release is gekoppeld, bijvoorbeeld release/20.

Maak vertakkingen om fouten uit de releasebranch op te lossen en deze weer samen te voegen in de releasevertakking in een pull-aanvraag.

Poortwijzigingen terug naar de hoofdbranch

Zorg ervoor dat fixes terechtkomen in zowel uw releasebranch als uw hoofdbranch. Een benadering is om oplossingen in de releasevertakking aan te brengen en vervolgens wijzigingen in uw hoofdvertakking te brengen om regressie in uw code te voorkomen. Een andere benadering (en de methode die wordt gebruikt door het Azure DevOps-team) is altijd wijzigingen aanbrengen in de hoofdlijn en deze vervolgens overzetten naar de releasebranch. Meer informatie over onze Release Flow-strategie kunt u lezen.

In dit onderwerp behandelen we het aanbrengen van wijzigingen in de releasevertakking en het overzetten ervan in mainline. Gebruik cherry-pick in plaats van samenvoegen, zodat u exact de controle hebt over welke doorvoeringen worden teruggezet naar de hoofdvertakking. Als u de releasevertakking samenvoegt in de hoofdvertakking, kunnen releasespecifieke wijzigingen worden doorgevoerd die u niet in de hoofdvertakking wilt opnemen.

Werk de hoofdbranch bij met een wijziging in de releasebranch met de volgende stappen:

1. Maak een nieuwe functiebranch van de hoofdbranch om de wijzigingen door te voeren.
2. Kies de wijzigingen uit de releasebranch naar uw nieuwe functievertakking.
3. Voeg de functiebranch weer samen in de hoofdbranch in een tweede pull-aanvraag.

Met deze release-vertakkingswerkstroom blijven de pijlers van de basiswerkstroom intact: functiebranches, pull-aanvragen en een sterke hoofdbranch die altijd de nieuwste versie van de code heeft.

Waarom niet tags gebruiken voor releases?

Andere vertakkingswerkstromen gebruiken Git-tags om een specifieke doorvoering als release te markeren. Tags zijn handig voor het markeren van punten in uw geschiedenis als belangrijk. Tags introduceren extra stappen in uw werkstroom die niet nodig zijn als u vertakkingen voor uw releases gebruikt.

Tags worden afzonderlijk van uw doorvoeringen onderhouden en gepusht. Teamleden kunnen eenvoudig het taggen van een doorvoering missen en daarna de geschiedenis moeten doorlopen om de tag te herstellen. U kunt ook de extra stap vergeten om de tag te pushen, zodat de volgende ontwikkelaar werkt vanuit een oudere versie van de code bij het ondersteunen van de release.

De releasebranchstrategie breidt de basiswerkstroom voor functiebranch uit om releases af te handelen. Uw team hoeft geen nieuw versiebeheerproces te gebruiken dan de kersenkiezer voor poortwijzigingen.

Implementaties beheren

U kunt meerdere implementaties van uw code afhandelen op dezelfde manier als u meerdere releases afhandelt. Maak een duidelijke naamconventie, zoals deploy/performance-test, en behandel de omgevingsvertakkingen zoals releasevertakkingen. Uw team moet akkoord gaan met een proces voor het bijwerken van implementatiebranches met de code uit uw hoofdbranch. Oplossingen voor kersenkiesfouten in de implementatievertakking terug naar de hoofdvertakking. Gebruik dezelfde stappen als het overzetten van wijzigingen vanuit een releasevertakking.

Een uitzondering op deze aanbeveling is als u een vorm van continue implementatie gebruikt. Gebruik Azure Pipelines bij het werken met continue implementatie om builds van uw hoofdbranch naar uw implementatiedoelen te promoveren.