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 incheckningarna av ämnesgrenen i huvudgrenen och skapar en sammanslagningscheckning för att stämma av eventuella konflikter mellan standard- och ämnesgrenen. Kommentarerna och diskussionen i pull-begäran ger ytterligare 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.

Squashsammanslagning

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 varje incheckning i ämnesgrenen som läggs till i standardgrenens historik lägger en squash-sammanslagning till alla filändringar i en enda ny incheckning på standardgrenen. Incheckning av squashsammanslagning har ingen referens till ämnesgrenen. Den skapar en ny incheckning som innehåller alla ändringar från ämnesgrenen. Dessutom rekommenderar vi att du tar bort ämnesgrenen för att förhindra förvirring.

Ett enkelt sätt att tänka på detta är att squashsammanslagning ger dig bara filändringarna, och en vanlig sammanslagning ger dig filändringarna och incheckningshistoriken.

Hur är en squashsammanslagning till hjälp?

Squashsammanslagning håller standardgrenshistoriken ren och lätt att följa utan att kräva några arbetsflödesändringar i ditt team. Deltagare i ämnesgrenen arbetar som de vill i ämnesgrenen, och standardgrenarna har 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 squashsammanslagning eller när du vill behålla hela incheckningshistoriken för en ämnesgren. När squash slås samman är det en bra idé att ta bort källgrenen. Om du tar bort källgrenen hindrar du förvirring eftersom själva ämnesgrenen inte har någon incheckning som sammanfogar den i standardgrenen.

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 (dvs. 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 för git merge-base --all feature master att göra det. 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 rapporter endast rapporterar en sammanslagningsbas.

Följande scenarier identifieras av Azure DevOps som flera baser (sammanslagningsbaserna anges med nummer 1 och 2):

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

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

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

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

• Hantering av efterdyningar av huvudgrensåterkopplingar, t.ex. ändra sammanslagningsincheckningen

*   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 manipuleringar med återställningar, körsbärsval och sammanslagningar

Basidentifiering för flera sammanslagning är en del av säkerhetsmedvetenheten. 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-begäran har olika versioner mellan kopplingsbaserna inträffar en varning om flera sammanslagningsbaser.

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 överordnad genom att antingen basera grenen på målet eller slå samman målet 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 mjuk återställning och stash dina framsteg innan ombasering eller sammanslagning. 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-begäran kan det återskapa situationen. Även om byggprinciper och tester körs kan du inte slutföra pull-begäran. Det kan vara bra 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ösa sammanslagningskonflikter
• Slutför en pull-begäran
• Om pull-begäranden