3.4 Git-grenar - Arbetsflöden med grenar

Eftersom Git använder enkel trevägssammanfogning är det i regel lätt att sammanfoga en gren in i en annan flera gånger under en längre period. Det betyder att du kan ha flera grenar som alltid är öppna och som används för olika steg i utvecklingscykeln; du kan regelbundet sammanfoga ändringar från vissa av dem in i andra.

Många Git-utvecklare använder ett arbetsflöde som bygger på detta, till exempel att bara ha helt stabil kod i sin master-gren – ofta bara kod som har publicerats eller ska publiceras som utgåva. De har en parallell gren som heter develop eller next som de arbetar i eller använder för att testa stabilitet – den är inte alltid stabil, men när den blir stabil kan den sammanfogas in i master. Den används för att dra in ämnesgrenar (kortlivade grenar, som din tidigare iss53-gren) när de är klara, så att man kan säkerställa att de klarar tester och inte introducerar fel.

I praktiken pratar vi om pekare som rör sig uppåt i raden av incheckningar du gör. De stabila grenarna ligger längre ner i historiken, och de mest nyskapande grenarna ligger längre upp.

Det är ofta enklare att tänka på dem som arbetsfack, där en uppsättning incheckningar flyttas till ett mer stabilt fack när de är fullt testade.

Du kan fortsätta så genom flera stabilitetsnivåer. Vissa större projekt har även en gren som heter proposed eller pu (föreslagna uppdateringar) som innehåller grenar som kanske inte är redo för next eller master. Tanken är att dina grenar ligger på olika stabilitetsnivåer; när de når en mer stabil nivå sammanfogas de in i grenen ovanför. Återigen: flera långlivade grenar är inte nödvändigt, men det är ofta hjälpsamt i stora eller komplexa projekt.

Ämnesgrenar är användbara i projekt av alla storlekar. En ämnesgren är en kortlivad gren som du skapar och använder för en enskild funktion eller ett sammanhängande arbete. Det här är något du troligen aldrig gjorde i äldre VCS:er eftersom det var för dyrt att skapa och sammanfoga grenar. Men i Git är det vanligt att skapa, arbeta på, sammanfoga och ta bort grenar flera gånger om dagen.

Du såg det i förra avsnittet med grenarna iss53 och hotfix. Du gjorde några incheckningar på dem och tog bort dem direkt efter att du sammanfogat dem med huvudgrenen. Tekniken gör att du kan byta kontext snabbt och helt – eftersom arbetet är isolerat i ett fack där alla ändringar har med just det ämnet att göra, blir det lättare att se vad som har hänt vid till exempel kodgranskning. Du kan låta ändringarna ligga där i minuter, dagar eller månader och sammanfoga dem när de är redo, oavsett i vilken ordning de skapades eller arbetades på.

Anta följande exempel: du gör lite arbete på master, skapar en gren för ett ärende (iss91), jobbar där ett tag, skapar en ny gren för att prova en annan lösning (iss91v2), går tillbaka till master och jobbar där en stund, och skapar sedan en ny gren för något du inte är säker på (dumbidea). Historiken kommer att se ut ungefär så här:

Anta nu att du gillar den andra lösningen bäst (iss91v2) och att du visat dumbidea för dina kollegor – och det visar sig vara genialt. Du kan då kasta den ursprungliga iss91-grenen (och förlora incheckningarna C5 och C6) och sammanfoga de två andra. Historiken ser då ut så här:

Vi går djupare in i möjliga arbetsflöden för Git i Distribuerat Git, så läs det kapitlet innan du bestämmer vilken grenmodell ditt nästa projekt ska använda.

Det är viktigt att komma ihåg att dessa grenar är helt lokala. När du skapar grenar och sammanfogar dem görs allt lokalt i ditt Git-kodförråd – ingen kommunikation sker med en server.