git-rerere - Återanvänd sparad lösning av sammanslagningskonflikter

I ett arbetsflöde som använder relativt långlivade ämnesgrenar, behöver utvecklaren ibland lösa samma konflikter om och om igen tills ämnesgrenarna är klara (antingen sammanslagna med "release"-grenen, eller skickade ut och accepterade uppströms).

Kommandot hjälper utvecklaren i processen genom att registrera motstridiga autosammanslå-resultat och motsvarande handlösningsresultat vid den initiala manuella sammanslagningen, och tillämpa tidigare registrerade handlösningar på deras motsvarande autosammanslå-resultat.

Normalt körs git rerere utan argument eller användarintervention. Den har dock flera kommandon som gör att den kan interagera med sitt arbetsläge.

När din ämnesgren modifierar ett överlappande område som din huvudgren (eller uppströms) har berört sedan din ämnesgren har förgrenat sig från den, kanske du vill testa den med den senaste huvudgrenen, redan innan din ämnesgren är redo att skickas uppströms:

För ett sådant test behöver du på något sätt slå samman master och ämne. Ett sätt att göra det är att dra master in i topic-grenen:

De incheckningar som är markerade med * berör samma område i samma fil; du måste lösa konflikterna när du skapar incheckningen som är markerad med +. Sedan kan du testa resultatet för att se till att ditt pågående arbete fortfarande fungerar med det som finns i den senaste master.

Efter denna testsammanslagning finns det två sätt att fortsätta arbetet med ämnet. Det enklaste är att bygga vidare på testsammanslagningsincheckningen +, och när arbetet i ämnesgrenen äntligen är klart, dra ämnesgrenen till mastern och/eller be uppströmsgrenen att hämta därifrån. Vid det laget kan dock mastern eller uppströmsgrenen ha avancerat sedan testsammanslagningen +, i vilket fall den slutliga incheckningsgrafen skulle se ut så här:

När ämnesgrenen är långlivad skulle den dock få många sådana "Sammanslagning från master"-incheckningar, vilket i onödan skulle skräpa in utvecklingshistoriken. Läsare av Linuxkärnans e-postlista kanske minns att Linus klagade över så frekventa testsammanslagningar när en delsystemsansvarig bad om att hämta från en gren full av "värdelösa sammanslagningar".

Som ett alternativ kan testsammanslagningen tas bort för att hålla ämnesgrenen ren från testsammanslagningar, och arbetet kan fortsätta ovanpå toppen före testsammanslagningen:

Det skulle bara lämna en sammanslagningsincheckning kvar när ämnesgren äntligen är klar och sammanfogad med huvudgrenen. Denna sammanslagning skulle kräva att konflikten löses, som introduceras av incheckningar markerade med *. Denna konflikt är dock ofta samma konflikt som löstes när testsammanslagningen skapades och sedan togs bort. git rerere hjälper till att lösa denna slutliga konfliktfyllda sammanslagning med hjälp av informationen från den tidigare manuella lösningen.

Om kommandot git rerere körs omedelbart efter en konfliktfylld autosammanslagning registreras de konfliktfyllda arbetsträdsfilerna, med de vanliga konfliktmarkörerna <<<<<<<<, ======= och >>>>>>> i dem. Senare, när konflikterna har lösts, kommer körning av git rerere igen att registrera det lösta tillståndet för dessa filer. Anta att detta gjordes när testmerge av master skapades i ämnesgrenen.

Nästa gång samma konfliktfyllda autosammanslagning uppstår kommer git rerere att utföra en trevägssammanslagning mellan den tidigare konfliktfyllda autosammanslagningen, den tidigare manuella lösningen och den nuvarande konfliktfyllda autosammanslagningen. Om denna trevägssammanslagning löses utan problem skrivs resultatet till arbetsträdsfilen, så att någon manuell lösning inte behövs. Observera att git rerere lämnar indexfilen orörd, så de slutliga rimlighetskontrollerna med git diff (eller git diff -c) och git add behöver fortfarande göras när resultatet är tillfredsställande.

Som en bekvämlighetsåtgärd, anropar git merge automatiskt git rerere vid avslutande med en misslyckad autosammanslagning och git rerere registrerar handlösningen när det är en ny konflikt, eller återanvänder den tidigare handlösningen när den inte är det. git commit anropar också git rerere vid incheckning av ett mergeresultat. Det betyder att det inte behövs något speciellt själv (förutom att aktivera konfigurationsvariabeln rerere.enabled).

I vårt exempel registreras den manuella lösningen när testsammanslagningen görs, och den kommer att återanvändas vid den faktiska sammanslagningen senare med den uppdaterade huvud- och ämnesgrenen, så länge den registrerade lösningen fortfarande är tillämplig.

Informationen git rerere används också när git rebase körs. Efter att ha blåst bort testsammanslagningen och fortsatt utveckling av ämnesgrenen:

git rebase master ämne kan köras för att uppdatera ämnesgrenen innan den är redo att skickas uppströms. Detta skulle resultera i att man återgår till en trevägssammanslagning, och det skulle skapa konflikter på samma sätt som testsammanslagningen som löstes tidigare. git rerere kommer att köras av git rebase för att hjälpa till att lösa denna konflikt.

[OBS] git rerere använder konfliktmarkörerna i filen för att upptäcka konflikten. Om filen redan innehåller rader som ser likadana ut som rader med konfliktmarkörer, kan git rerere misslyckas med att registrera en konfliktlösning. För att kringgå detta kan inställningen conflict-marker-size i gitattributes[5] användas.

En del av git[1]-sviten