Använda en förgreningsstrategi på Git

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Distribuerade versionskontrollsystem som Git ger dig flexibilitet i hur du använder versionskontroll för att dela och hantera kod. Ditt team bör hitta en balans mellan den här flexibiliteten och behovet av att samarbeta och dela kod på ett konsekvent sätt.

Teammedlemmar publicerar, delar, granskar och itererar kodändringar via Git-grenar som delas med andra. Anta en förgreningsstrategi för ditt team. Du kan samarbeta bättre och ägna mindre tid åt att hantera versionskontroll och mer tid på att utveckla kod.

Följande förgreningsstrategier baseras på hur vi använder Git här på Microsoft. Mer information finns i Så här använder vi Git på Microsoft.

Håll din grenstrategi enkel

Håll din grenstrategi enkel. Skapa din strategi utifrån dessa tre begrepp:

• Använd funktionsgrenar för alla nya funktioner och buggkorrigeringar.
• Sammanfoga funktionsgrenar till huvudgrenen med hjälp av pull-begäranden.
• Håll en uppdaterad huvudgren av hög kvalitet.

En strategi som utökar dessa begrepp och undviker motsägelser resulterar i ett arbetsflöde för versionskontroll för ditt team som är konsekvent och lätt att följa.

Använda funktionsgrenar för ditt arbete

Utveckla dina funktioner och åtgärda buggar i funktionsgrenar baserat på din huvudgren. Dessa grenar kallas även ämnesgrenar. Funktionsgrenar isolerar pågående arbete från det slutförda arbetet i huvudgrenen. Git-grenar är billiga att skapa och underhålla. Även små korrigeringar och ändringar bör ha en egen funktionsgren.

Att skapa funktionsgrenar för alla dina ändringar gör granskningshistoriken enkel. Titta på incheckningarna som gjorts i grenen och titta på pull-begäran som sammanfogade grenen.

Namnge dina funktionsgrenar efter konvention

Använd en konsekvent namngivningskonvention för dina funktionsgrenar för att identifiera det arbete som utförs i grenen. Du kan också inkludera annan information i grennamnet, till exempel vem som skapade grenen.

Några förslag på hur du namnger dina funktionsgrenar:

• användare/användarnamn/beskrivning
• användare/användarnamn/workitem
• bugfix/description
• funktion/funktionsnamn
• feature/feature-area/feature-name
• snabbkorrigering/beskrivning

Använda funktionsflaggor för att hantera långvariga grenar

Läs mer om hur du använder funktionsflaggor i koden.

Granska och sammanfoga kod med pull-begäranden

Granskningen som sker i en pull-begäran är viktig för att förbättra kodkvaliteten. Slå bara samman grenar via pull-begäranden som godkänns i granskningsprocessen. Undvik att slå samman grenar till huvudgrenen utan en pull-begäran.

Det tar tid att slutföra granskningar i pull-begäranden. Ditt team bör komma överens om vad som förväntas av pull-begärandeskapare och granskare. Distribuera granskaransvar för att dela idéer i ditt team och sprida ut kunskap om din kodbas.

Några förslag på lyckade pull-begäranden:

• Två granskare är ett optimalt tal baserat på forskning.
• Om ditt team redan har en process för kodgranskning kan du ta med pull-begäranden till det du redan gör.
• Var noga med att tilldela samma granskare till ett stort antal pull-begäranden. Pull-begäranden fungerar bättre när granskarnas ansvar delas i hela teamet.
• Ange tillräckligt med information i beskrivningen för att snabbt få granskarna att komma igång med dina ändringar.
• Inkludera en version eller länkad version av dina ändringar som körs i en mellanlagrad miljö med din pull-begäran. Andra kan enkelt testa ändringarna.

Håll en uppdaterad huvudgren av hög kvalitet

Koden i huvudgrenen ska klara tester, bygga rent och alltid vara aktuell. Huvudgrenen behöver dessa egenskaper så att funktionsgrenar som skapats av ditt team börjar från en känd bra kodversion.

Konfigurera en grenprincip för din huvudgren som:

• Kräver en pull-begäran för att slå samman kod. Den här metoden förhindrar direkt push-överföring till huvudgrenen och säkerställer diskussioner om föreslagna ändringar.
• Lägger automatiskt till granskare när en pull-begäran skapas. De teammedlemmar som lagts till granskar koden och kommenterar ändringarna i pull-begäran.
• Kräver en lyckad version för att slutföra en pull-begäran. Kod som sammanfogas till huvudgrenen bör byggas rent.

Hantera versioner

Använd versionsgrenar för att samordna och stabilisera ändringar i en version av koden. Den här grenen är långlivad och sammanfogas inte tillbaka till huvudgrenen i en pull-begäran, till skillnad från funktionsgrenarna. Skapa så många versionsgrenar som du behöver. Tänk på att varje aktiv versionsgren representerar en annan version av koden som du behöver stöd för. Lås versionsgrenar när du är redo att sluta stödja en viss version.

Använda versionsgrenar

Skapa en versionsgren från huvudgrenen när du kommer nära din version eller annan milstolpe, till exempel slutet av en sprint. Ge den här grenen ett tydligt namn som associerar den med versionen, till exempel release/20.

Skapa grenar för att åtgärda buggar från versionsgrenen och sammanfoga dem tillbaka till versionsgrenen i en pull-begäran.

Porten ändras tillbaka till huvudgrenen

Se till att korrigeringarna hamnar i både versionsgrenen och huvudgrenen. En metod är att göra korrigeringar i versionsgrenen och sedan lägga till ändringar i huvudgrenen för att förhindra regression i koden. En annan metod (och den som används av Azure DevOps-teamet) är att alltid göra ändringar i huvudlinjen och sedan portera dem till versionsgrenen. Du kan läsa mer om vår Strategi för versionsflöde .

I det här avsnittet går vi igenom hur du gör ändringar i versionsgrenen och porterar dem till huvudlinjen. Använd körsbärsplockning i stället för att slå samman så att du har exakt kontroll över vilka incheckningar som portas tillbaka till huvudgrenen. Om du sammanfogar versionsgrenen till huvudgrenen kan du ta över versionsspecifika ändringar som du inte vill ha i huvudgrenen.

Uppdatera huvudgrenen med en ändring som gjorts i versionsgrenen med följande steg:

1. Skapa en ny funktionsgren utanför huvudgrenen för att porta ändringarna.
2. Välj ändringarna från versionsgrenen till din nya funktionsgren.
3. Sammanfoga funktionsgrenen tillbaka till huvudgrenen i en andra pull-begäran.

Det här arbetsflödet för versionsgrenen håller grundpelarna i det grundläggande arbetsflödet intakta: funktionsgrenar, pull-begäranden och en stark huvudgren som alltid har den senaste versionen av koden.

Varför inte använda taggar för versioner?

Andra förgreningsarbetsflöden använder Git-taggar för att markera en specifik incheckning som en version. Taggar är användbara för att markera punkter i din historik som viktiga. Taggar introducerar extra steg i arbetsflödet som inte behövs om du använder grenar för dina versioner.

Taggar underhålls och push-överförs separat från dina incheckningar. Teammedlemmar kan enkelt missa taggning av en incheckning och måste sedan gå tillbaka genom historiken efteråt för att åtgärda taggen. Du kan också glömma det extra steget för att push-överföra taggen, vilket gör att nästa utvecklare arbetar från en äldre version av koden när de stöder versionen.

Strategin för versionsgren utökar arbetsflödet för den grundläggande funktionsgrenen för att hantera versioner. Ditt team behöver inte införa någon annan versionskontrollprocess än cherry-pick till portändringar.

Hantera distributioner

Du kan hantera flera distributioner av koden på samma sätt som du hanterar flera versioner. Skapa en tydlig namngivningskonvention, till exempel distribuera/prestandatesta, och behandla miljögrenarna som versionsgrenar. Ditt team bör komma överens om en process för att uppdatera distributionsgrenar med koden från huvudgrenen. Buggkorrigeringar för cherry-pick i distributionsgrenen tillbaka till huvudgrenen. Använd samma steg som att portera ändringar från en versionsgren.

Ett undantag till den här rekommendationen är om du använder en form av kontinuerlig distribution. Använd Azure Pipelines när du arbetar med kontinuerlig distribution för att höja upp byggen från din huvudgren till dina distributionsmål.