Sammanslagningsstrategier och squashsammanslagning

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

När du slutför en pull-begäran sammanfogar du ämnesgrenen till din standardgren, vanligtvis main. Den här sammanfogningen lägger till kommitteringar från ämnesgrenen till huvudgrenen och skapar en sammanslagningskommittering för att lösa eventuella konflikter mellan huvud- och ämnesgrenen. Kommentarerna och diskussionen i pull-begäran ger mer kontext för de ändringar som gjorts i ämnesgrenen.

Incheckningshistoriken för din main gren (eller annan standardgren) följer inte en rak linje på grund av den relaterade ämnesgrenhistoriken. I takt med att ett projekt växer ökar antalet ämnesgrenar som bearbetas samtidigt, vilket gör standardgrenens historik allt svårare att följa.

Standardgrenen är en korrekt representation av historiken för varje ämnesgren, men det är svårt att använda för att besvara bredare frågor om projektets utveckling.

Förutsättningar

Kategori	Krav
Åtkomst till projekt	Medlem av ett -projekt.
behörigheter	Visa kod i privata projekt: Minst grundläggande åtkomst . – Klona eller bidra till kod i privata projekt: Medlem i Bidragsgivare säkerhetsgrupp eller projektets motsvarande behörigheter. – Ange behörigheter för gren eller lagringsplats: Hantera behörigheter behörigheter för grenen eller lagringsplatsen. – Ändra standardgren: Redigera principer behörigheter för lagringsplatsen. – Importera en lagringsplats: Medlem i Projektadministratörer säkerhetsgrupp eller Git-projektnivå Skapa lagringsplats behörighet inställd på Tillåt. Mer information finns i Ange Behörigheter för Git-lagringsplats.
Tjänster	Repos aktiverat.
Verktyg	Valfritt. Använd kommandona az repos: Azure DevOps CLI.

Anmärkning

I offentliga projekt har användare med åtkomst på intressentnivå fullständig åtkomst till Azure Repos, inklusive att se, klona och bidra till kod.

Squash merge (sammanslagning)

Squashsammanslagning är ett sammanslagningsalternativ som gör att du kan komprimera Git-historiken för ämnesgrenar när du slutför en pull-begäran. I stället för att lägga till varje incheckning i ämnesgrenen i historiken för standardgrenen lägger en squash-sammanslagning till alla filändringar i en enda ny incheckning på standardgrenen. Sammanslagningsåtagande för squash har ingen referens till funktionsgrenen. Den skapar en ny incheckning som innehåller alla ändringar från ämnesgrenen. Vi rekommenderar att du tar bort ämnesgrenen för att förhindra förvirring.

Ett enkelt sätt att tänka på detta är att squash-merge ger dig bara filändringarna, och en vanlig sammanslagning ger dig filändringarna och versionshistoriken.

Hur är en squashsammanslagning till hjälp?

Squashsammanslagning håller historiken för standardgrenen ren och lätt att följa utan att kräva några arbetsflödesändringar för ditt team. Deltagare i ämnesgrenen arbetar som de vill i ämnesgrenen, och standardgrenarna behåller en linjär historik med hjälp av squashsammanslagningar. Incheckningshistoriken för en main gren som uppdateras med squashsammanslagningar har en incheckning för varje sammanslagen gren. Du kan gå igenom den här historiken för att ta reda på exakt när arbetet utfördes.

Överväganden vid sammanslagning av squash

Squashsammanslagning komprimerar historiken för ändringar i din standardgren, så det är viktigt att arbeta med ditt team för att bestämma när du ska krossa sammanfogning jämfört med att behålla hela incheckningshistoriken för en ämnesgren. När man utför en squash-sammanslagning är det god praxis att ta bort ursprungsgrenen. Om du tar bort källgrenen hindrar du förvirring eftersom själva ämnesgrenen inte har någon incheckning som sammanfogar den i standardgrenen.

Slutför pull-förfrågningar med squash-merge

Du kan välja att göra en squash-sammanslagning när du slutför en pull-förfrågan i Azure Repos.

Välj Squash-sammanfogning under Sammanfogningstyp i Slutför pull request-dialogrutan för att squash-sammanfoga ämnesgrenen.

Flera sammanslagningsbaser

Fliken Filer i en pull-begäran identifierar diffs med en jämförelse på tre sidor. Algoritmen tar hänsyn till den senaste incheckningen i målgrenen, den sista incheckningen i källgrenen och deras gemensamma kopplingsbas, till exempel den bästa gemensamma överordnade. Algoritmen är en snabb, kostnadseffektiv och tillförlitlig metod för att identifiera ändringar. Tyvärr finns det i vissa fall mer än en sann bas. I de flesta lagringsplatser är den här situationen sällsynt, men i stora lagringsplatser med många aktiva användare kan det vara vanligt. Du kan kontrollera manuellt om det finns flera kopplingsbaser mellan grenarna. Kör kommandot git merge-base --all feature master. Azure DevOps identifierar förekomsten av flera sammanslagningsbaser för varje PR. När dessa identifieras visar Azure DevOps meddelandet "Flera sammanslagningsbaser har identifierats. Listan över incheckningar som visas kan vara ofullständig" för PR. Även om Azure DevOps kör identifieringen av flera sammanslagningsbaser kontrollerar den inte om den potentiella sammanslagningsbasen redan har sammanfogats eller inte. Sådan kontroll görs av git merge-base. Därför kan Azure DevOps visa meddelandet även när git merge-base rapporterar endast en mergebas.

Anmärkning

Om du har missat ändringar vid en PR-granskning, se till att flera sammanslagningsbaser inte är rotorsaken.

Följande exempelscenarier identifieras av Azure DevOps som flera baser, med sammanslagningsbaserna som anges av nummer ett och två:

• Korskopplingar (kallas även korsningar) mellan olika grenar (rapporteras av Azure DevOps och git merge-base)

---1---o---A
    \ /
     X
    / \
---2---o---o---B

• Sammanslagning av en gren till två andra (rapporterat av Azure DevOps, men inte av git merge-base som eliminerar sammanslagningsbasen 2)

---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B

• Hantering av efterdyningar av återsställningar av huvudgrenen, till exempel ändra sammanslagningskommittén

*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init

• Aktiv återanvändning av funktionsgrenar
• Andra icke-intuitiva och invecklade hanteringar med återställningar, selektiva val och sammanslagningar

Identifiering av flera baser för sammanfogning är en del av säkerhetsmedvetenhet. Om det finns flera kopplingsbaser kanske fil-diff-algoritmen för användargränssnittet inte identifierar filändringar korrekt, beroende på vilken kopplingsbas den väljer. Om filerna i pull requesten har olika versioner mellan merge-baserna, inträffar en varning om flera merge-baser.

Mer information finns i den officiella Git-dokumentationen .

Potentiella säkerhetsrisker vid sammanslagning från flera baser

• En obehörig användare kan missbruka UI-algoritmen för att genomföra skadliga ändringar som inte finns i PR.
• Om ändringar som föreslås i PR redan finns i målgrenen visas de på fliken Filer , men de kanske inte utlöser grenprinciper som mappas till mappändringar.
• Två uppsättningar med ändringar i samma filer från flera sammanslagningsbaser kanske inte finns i PR. Det här fallet kan skapa förrädiska logikluckor.

Så här löser du problemet med flera sammanslagningsbaser

Att ha flera sammanslagningsbaser är inte nödvändigtvis dåligt, men du bör dubbelkolla att allt är bra. Om du vill bli av med flera sammanslagningsbaser kopplar du grenarna till en enda gemensam förfader genom att antingen göra om din gren baserat på målgrenen eller slå samman målgrenen i din gren. Dessa åtgärder gör dig av med varningsmeddelandet och hjälper dig att kontrollera om de faktiska ändringarna är bra.

En metod är att göra en mjuk återställning och spara dina framsteg innan du ombaserar eller slår samman. Du kan sedan skapa en ny gren eller ombasera en tom gren och tillämpa ändringarna från en tydlig punkt. Den här processen kan kräva en force push-överföring till fjärranslutningen om ändringarna redan finns där.

Så här undviker du problemet med flera sammanslagningsbaser

Här är allmänna tips för att undvika problemet med flera sammanslagningsbaser:

• När du förbereder en pull-begäran skapar du funktionsgrenar från de senaste versionerna av huvud- eller versionsgrenen.
• Undvik att skapa grenar som inte kommer direkt från stabila grenar på lagringsplatsen, såvida det inte krävs.

Vad gör du om problemet med flera sammanslagningsbaser visas igen

I stora lagringsplatser med många aktiva deltagare kan det här problemet vara särskilt obekvämt. Även om du blir av med flera baser via sammanslagning kan situationen dyka upp igen. Om någon stänger en långvarig pull request kan det leda till att situationen återuppstår. Även om byggprinciper och tester körs har du inget sätt att slutföra pull-förfrågan. Det kan hjälpa att återställa och starta en ny gren. Om inget ändras är dina ändringar förmodligen tydliga, även om situationen upprepar sig.

Nästa steg

• Lös sammanslagningskonflikter
• Slutför en pull-begäran
• Om pull-begäranden