3.2 Git-grenar - Grundläggande gren- och sammanfogningsarbete

Anta att du arbetar på ett projekt och redan har gjort några incheckningar på master-grenen.

Du har bestämt dig för att jobba med ärende #53 i organisationens ärendehanteringssystem. För att skapa en ny gren och byta till den samtidigt kan du köra git checkout med flaggan -b:

Det här är kort för:

Du arbetar på webbplatsen och gör några incheckningar. Då flyttas iss53-grenen framåt, eftersom du har den växlad till (det vill säga HEAD pekar på den):

Nu får du samtalet om att det finns ett problem med webbplatsen som måste fixas omgående. Med Git behöver du inte distribuera din fix tillsammans med iss53-ändringarna, och du behöver inte lägga tid på att ångra dem innan du kan jobba mot produktion. Allt du behöver göra är att byta tillbaka till master.

Notera dock att om arbetskatalogen eller köytan innehåller icke checkade in ändringar som krockar med grenen du vill växla till, kommer Git att hindra bytet. Det är bäst att ha en ren arbetskatalog när du byter gren. Det finns sätt att komma runt detta (gömma ändringar eller göra en tilläggsincheckning), vilket vi går igenom senare i Lägga undan och städa. För tillfället antar vi att du har checkat in allt och kan byta tillbaka till master:

Nu ser arbetskatalogen ut exakt som den gjorde innan du började jobba på ärende #53, och du kan fokusera på snabbkorrigeringen. Det är viktigt att komma ihåg: när du byter gren återställer Git arbetskatalogen till hur den såg ut senast du checkade in på den grenen. Git lägger till, tar bort och ändrar filer automatiskt så att arbetskopian motsvarar grenen vid senaste incheckningen.

Nu ska du göra en snabbkorrigering. Låt oss skapa en hotfix-gren att arbeta i tills den är klar:

Du kan köra testerna, säkerställa att fixen är korrekt och sedan sammanfoga hotfix-grenen tillbaka till master för att publicera till produktion. Det gör du med git merge:

I utskriften ser du att Git snabbspolar. Eftersom incheckningen C4 som hotfix pekar på ligger direkt framför C2 som du står på, flyttar Git helt enkelt pekaren framåt. Med andra ord: när du försöker sammanfoga en incheckning med en incheckning som redan finns i historiken, gör Git saken enkel genom att flytta pekaren framåt – det finns ingen divergerad historik att sammanfoga.

Din ändring finns nu i ögonblicksbilden som master pekar på och du kan rulla ut fixen.

Efter att den viktiga korrigeringen är ute är du redo att gå tillbaka till arbetet du gjorde innan du blev avbruten. Men först tar du bort hotfix-grenen, eftersom du inte längre behöver den – master pekar på samma ställe. Du tar bort den med -d till git branch:

Nu kan du byta tillbaka till grenen för ärende #53 och fortsätta där:

Det är värt att notera att arbetet du gjorde i hotfix-grenen inte finns i iss53. Om du behöver få in ändringarna kan du sammanfoga master in i iss53 med git merge master, eller vänta tills du senare sammanfogar iss53 till master.

Anta att du bestämt dig för att arbetet med ärende #53 är klart och att det ska slås samman med master. Då slår du ihop iss53 med master, precis som du gjorde med hotfix tidigare. Allt du behöver göra är att växla till grenen du vill sammanfoga till och köra git merge:

Det här ser annorlunda ut än hotfix-sammanslagningen. Nu har historiken divergerat från en äldre punkt. Eftersom incheckningen på grenen du står på inte är en direkt förfader till grenen du slår ihop måste Git göra mer arbete. I det här fallet gör Git en enkel trevägssammanfogning, där två ögonblicksbilder och den gemensamma förfadern används.

I stället för att bara flytta grenpekaren framåt skapar Git en ny ögonblicksbild som är resultatet av trevägssammanfogningen och skapar automatiskt en ny incheckning som pekar på den. Detta kallas en sammanslagningsincheckning och den är speciell eftersom den har fler än en förälder.

Nu när arbetet är sammanfogat behöver du inte iss53 längre. Du kan stänga ärendet i ärendehanteringen och ta bort grenen:

Ibland går inte processen helt smärtfritt. Om du har ändrat samma del av samma fil på olika sätt i två grenar kan Git inte sammanfoga dem rent. Om din fix för ärende #53 ändrade samma del av en fil som hotfix-grenen får du en sammanslagningskonflikt som kan se ut så här:

Git har inte skapat någon sammanslagningsincheckning. Den har pausat processen medan du löser konflikten. Om du vill se vilka filer som inte är sammanfogade kan du köra git status:

Allt som har konflikter och inte har lösts listas som osammanfogat. Git lägger till standardmarkörer i filerna med konflikter så att du kan öppna dem och lösa konflikten manuellt. Din fil innehåller ett avsnitt som ser ut ungefär så här:

Detta betyder att versionen i HEAD (din master-gren, eftersom den var växlad till när du körde sammanslagningen) är den övre delen av blocket, medan versionen i iss53 är den nedre. För att lösa konflikten måste du välja en sida eller sammanfoga innehållet själv. Du kan till exempel ersätta hela blocket med:

Den lösningen har lite av båda, och raderna med <<<<<<<, ======= och >>>>>>> har tagits bort. När du löst varje konflikt i filen kör du git add på filen för att markera den som löst. Att köa filen markerar den som löst i Git.

Om du vill använda ett grafiskt verktyg kan du köra git mergetool, som startar ett lämpligt visuellt sammanslagningsverktyg och hjälper dig igenom konflikterna:

Om du vill använda ett annat verktyg än standard (Git valde opendiff här eftersom kommandot kördes på macOS) kan du se alla stödda verktyg i listan. Ange bara namnet på det verktyg du föredrar.

Efter att du avslutat verktyget frågar Git om sammanslagningen lyckades. Svarar du ja köas filen som löst. Du kan köra git status igen för att kontrollera att alla konflikter är lösta:

Om du är nöjd och har verifierat att allt är köat kan du skriva git commit för att slutföra sammanslagningsincheckningen. Standardmeddelandet för en sammanslagning ser ut ungefär så här:

Om du tycker att det vore hjälpsamt för andra att förstå vad som hände kan du skriva ett meddelande med detaljer om hur du löste konflikten och varför du gjorde vissa ändringar.