5.3 Distribuerade Git - Underhålla ett projekt

Om du har fått patchen av någon som genererade den med git diff eller någon variant av Unix diff-kommandot (rekommenderas inte; se mer i nästa avsnitt), kan du applicera den med git apply. Om vi utgår från att du sparade patchen på /tmp/patch-ruby-client.patch, ser det ut så här:

Kommandot ändrar filerna i ditt lokala arkiv. Det är nästan identiskt som att köra patch -p1 för att applicera patchen, men det accepterar inte lika luddiga matchningar som patch. Det hanterar också filer som läggs till, tas bort och döps om om de beskrivs i git diff-formatet, vilket patch inte gör. Slutligen är git apply en “applicera allt eller avbryt allt”-modell, där allt eller inget appliceras. patch kan å andra sidan applicera delar av patchfiler, men det kan lämna ditt lokala arkiv i ett lite märkligt tillstånd. Övergripande sett är git apply ett mer konservativt kommando än patch. Det kommer inte att göra en inceckning åt dig — när du har kört kommandot behöver du köa och checka in ändringarna manuellt.

git apply kan också användas för att se om en patch kan läggas till utan konflikter innan du försöker applicera den — kör git apply --check följt av patchen-filen:

Om det inte finns någon utdata kan patchen integreras utan problem. Detta kommando avslutar med ett nollskilt tal om kontrollen misslyckas, så det kan användas i skript med om du vill.

Om bidragslämnaren är en van Git-användare som använde kommandot format-patch för att generera sin patch, blir ditt jobb genast enklare. Patchen innehåller då även författarinformation och ett incheckningsmeddelande. Om du har möjlighet, uppmuntra dina bidragslämnare att använda format-patch istället för diff för att generera patchar till ditt projekt. git apply borde bara användas för patchar till legacy projekt.

För att applicera en patch som genererats av format-patch använder du git am (kommandot heter am eftersom det används för att "applicera en serie patchar från en mejlbox"). Tekniskt sett är git am byggt för att läsa en mbox-fil, som är ett enkelt, textbaserat format för att lagra ett eller flera e-postmeddelanden i en textfil. Det ser ut så här:

Det här är början på utdata från git format-patch-kommandot som du såg i föregående avsnitt; det är också ett giltigt mbox-e-postformat. Om någon har mejlat patchen till dig på rätt sätt med git send-email och du laddar ner den i mbox-format, kan du peka git am till mbox-filen för att den ska börja applicera alla patchar den ser. Om du använder en mejlklient som kan spara flera mejl i mbox-format, kan hela patchserier sparas i en fil och sen kan du köra git am för att applicera dem en i sänder.

Om någon däremot laddade upp en patchfil som genererats via git format-patch till ett ärendehanteringssystem eller liknande, kan du spara filen lokalt och sedan köra git am för att applicera den:

Den applicerades utan konflikt och skapade automatiskt en ny incheckning åt dig. Informationen om författaren tas från mejlets Från- och Datum-rubriker, meddelandet i incheckningen tas från Ämne och brödtexten (innan patchen) i mejlet. Om den här patchen applicerades från mbox-exemplet ovan, skulle den genererade incheckningen se ut ungefär så här:

Incheckningsinformationen anger vem som applicerade patchen och vid vilken tidpunkt. Författarinformation anger vem som skapade den och när.

Det är inte omöjligt att patchen inte kan appliceras på grund av konflikter. Kanske har din huvudgren divergerat för långt från den gren patchen byggdes från, eller så förgrenades den från en patch som du inte har applicerat än. git am-processen kommer då att misslyckas och du blir tillfrågad om hur du vill lösa konflikten:

Det här kommandot anger i vilka berörda filer det finns konflikter, precis som vid en sammanslagning eller ombasering. Du löser det här problemet på ungefär samma sätt — redigerar filen för att lösa konflikten, köar den nya filen och kör sedan git am --resolved för att fortsätta till nästa patch:

Om du vill att Git ska försöka göra en lite mer intelligent operation för att lösa konflikten kan du lägga till en -3-flagga. Git försöker då att göra en trefältsfusion. Det är inte förvalt eftersom det inte fungerar om den incheckning som patchen förgrenades ifrån inte finns i ditt arkiv. Om patchen däremot förgrenades från en offentlig incheckning är -3-flaggan generellt mycket smartare för att applicera en patch med konflikter:

Utan -3-flaggan skulle patchen i det här fallet ha betraktats som konfliktfylld. Med -3-flaggan appliceras den utan problem.

Om du applicerar ett helt gäng patcher från en mbox kan du också köra am-kommandot i interaktivt läge, vilket stannar processen vid varje patch för att fråga om du vill applicera den:

Det här är användbart om du har många patcher för att kunna se dem först om du inte skulle komma ihåg vad någon handlar om, eller hoppa över någon som du redan har lagt till.

När alla patcher har lagts till och checkats in i din gren behöver du bestämma om och hur du ska integrera dem i en långlivad gren.

Ett grundläggande arbetsflöde är att helt enkelt slå ihop allt arbete direkt i din master-gren. I det här scenariot har du en master-gren som innehåller stabil kod. När du har arbete i en funktionsgren som du tror att du har slutfört, eller arbete som någon annan har bidragit med och du har verifierat, slår du ihop det i din master-gren, tar bort den just sammanfogade temagrenen och upprepar.

Om vi har ett arkiv med arbete i två grenar som heter ruby_client och php_client som ser ut som Historik med flera funktionsgrenar, och vi slår ihop ruby_client följt av php_client, kommer din historik att se ut som Efter en sammanslagning med en funktionsgren..

Det här är förmodligen det enklaste arbetsflödet, men det kan bli problematiskt om du arbetar med större eller mer stabila projekt där du vill vara riktigt försiktig med vad du introducerar.

Om du har ett viktigare projekt kanske du vill använda en tvåfas-sammanslagningcykel. I det scenariot har du två långlivade grenar, master och develop, där du bestämmer att master uppdateras endast när en mycket stabil version skapas och all ny kod integreras i develop-grenen. Du skickar regelbundet båda dessa grenar till det publika arkivet. Varje gång du har en ny funktionsgren att slå ihop (Före en sammanslagning av en funktionsgren.), slår du ihop den i develop (Efter en sammanslagning av en funktionsgren.); sedan, när du taggar en version, snabbspolar du master till där develop-grenen är stabil (Efter en ny version.).

På det här sättet, när folk klonar ditt projekts arkiv, kan de antingen kolla ut master för att bygga den senaste stabila versionen och enkelt hålla sig uppdaterade på den, eller kolla ut develop, som är den mer skärpta innehållet. Du kan också utöka det här konceptet genom att ha en integrate-gren där allt arbete sammanfogas. När kodbasen på den grenen är stabil och passerar tester, slår du ihop den i en develop-gren; och när den har visat sig vara stabil under en tid, snabbspolar du din master-gren.

Git-projektet har fyra långlivade grenar: master, next och pu (proposed updates) för nytt arbete, och maint för underhållsbackportar. När nytt arbete introduceras av bidragslämnare samlas det i temagrenar i förvaltarens arkiv på ett sätt som liknar det som har beskrivits (se Hantera en komplex serie med parallella ämnesgrenar.). Vid det här laget utvärderas temana för att avgöra om de är säkra och redo för användning eller om de behöver mer arbete. Om de är säkra slås de ihop i next, och den grenen pushas upp så att alla kan prova temana integrerade tillsammans.

Om det behövs mer arbete på en temagren slås den ihop med pu istället. När det har bestämts att de är helt stabila slås de ihop med master-grenen. next- och pu-grenarna byggs sedan om från master. Det här innebär att master nästan alltid rör sig framåt, next ombaseras ibland, och pu ombaseras ännu oftare:

När en ämnesgren äntligen har slagits ihop med master-grenen tas den bort från arkivet. Git-projektet hr också en maint-gren som är en gren som är förgrenad från den senaste versionen för att tillhandahålla bakåtkompatibla patchar om en underhållsversion krävs. Så, när du klonar Git-arkivet har du fyra grenar som du kan kolla ut för att utvärdera projektet i olika utvecklingsstadier, beroende på hur nyskapande du vill vara eller hur du vill bidra; och förvaltaren har ett strukturerat arbetsflöde för att hjälpas åt att granska nya bidrag. Git-projektet har ett specialiserat arbetsflöde. För att förstå det bättre kan du läsa mer på Git Maintainer’s guide.

När du har arbete i en temagren och har bestämt att du vill integrera det, kan du göra det på två sätt: genom att ombasera eller plocka russin ur kakan. Vissa förvaltare föredrar att ombasera eller plocka russin ur kakan för att hålla en mestadels linjär historik. När du har arbete i en temagren och har bestämt att du vill integrera det, flyttar du till den grenen och kör ombasera-kommandot för att bygga om ändringarna på din nuvarande master-gren (eller develop, och så vidare). Om det går bra kan du snabbspola din master-gren. I slutänden får du en linjär projektshistorik.

Ett annat sätt att flytta in arbete från en gren till en annan är att plocka russin ur kakan. Att plocka russin ur kakan i Git är som en ombasering men för en enskild incheckning. Det tar en patch från en incheckning och försöker applicera den på den gren du är på. Detta är användbart om du har ett antal incheckningar på en temagren och du baran vill integrera en av dem, eller om du föredrar att plocka in incheckningarna en och en istället för att göra en ombasering. Om du till exempel har ett projekt som ser ut så här:

Om du vill dra in incheckningen e43a6 i din master-gren kan du köra

Det här drar in ändringarna i incheckning e43a6 in i din master-gren., men du får ett nytt SHA-1-värde för incheckningen eftersom datumet som den tillämpades är annorlunda. Din historik ser nu ut så här:

Nu kan du radera din funktionsgren och släppa incheckningarna som du inte vill få in.

Om du gör massor av sammanslagningar och ombaseringar, eller om du underhåller en långlivad funktionsgren, har Git en funktion som heter “rerere” som kan vara användbar.

Rerere står för “reuse recorded resolution” — det är ett sätt att förkorta manuell konflikthantering. När rerere är aktiverat kommer Git att behålla en uppsättning före- och efterbilder från lyckade sammanslagningar, och om det märker att det finns en konflikt som ser precis ut som en du redan har löst, kommer Git bara att använda lösningen från förra gången, utan att störa dig med den. Rerere stands for “reuse recorded resolution” — it’s a way of shortcutting manual conflict resolution. When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there’s a conflict that looks exactly like one you’ve already fixed, it’ll just use the fix from last time, without bothering you with it.

Funktionen har två delar: en konfigurationsinställning och ett kommando. Konfigurationsinställningen är rerere.enabled, och det är tillräckligt användbart för att lägga i din globala konfiguration:

När du än gör en sammanslagning som löser konflikter, kommer lösningen nu att sparas i cachen om den skulle behövas i framtiden.

Om du behöver kan du interagera med rerere-cachen med hjälp av kommandot git rerere. När det används ensamt, kollar Git sin databas med lösningar och försöker hitta en matchning med eventuella aktuella konflikter och lösa dem (även om det görs automatiskt om rerere.enabled är inställt på true). Det finns också underkommandon för att se vad som kommer att sparas, för att radera specifika lösningar från cachen och för att rensa hela cachen. Vi kommer att gå in på rerere mer i detalj i Rerere.