3.4 Git förgreningar - Arbetsflöde med grenar

Eftersom Git använder en enkel trevägssammanslagning är det generellt mycket enkelt att slå ihop en gren in i en annan flera gånger över en längre period. Detta betyder att du kan ha flera grenar som alltid finns och som du använder för olika steg i utvecklingen. Du kan regelbundet slå samman ändringar från några av dem in i andra.

Många Gitutvecklare har ett arbetsflöde som omfamnar detta tillvägagångssätt, som t.ex. att bara ha helt stabil kod i sin master-gren — möjligtvis bara kod som har eller skall frisläppas. De har en annan parallell gren benämnd develop eller next som de jobbar från och använder för att testa stabiliteten — den är inte nödvändigtvis alltid stabil, men när när den når ett stabilt tillstånd kan den slås ihop med master. Den används för att dra in ämnesgrenar (kortlivade grenar, som din förra iss53-gren) när de är färdigställda, för att säkerställa att de klarar alla tester och inte introducerar buggar.

I verkligheten pratar vi om pekare som förflyttar sig upp igenom raden av versioner som du skapar. De stabila grenarna är längre ner i din versionshistorik och grenerna som innehåller det absolut nyaste är längre upp.

Det är generellt enklare att tänka på dem som silos, där en uppsättning versioner promoveras till en mer stabil silo då de är fullt testade.

Du kan fortsätta med detta för flera nivåer av stabilitet. Några större projekt har även en gren benämnd proposed eller pu (proposed uppdates, sv. föreslagna uppdateringar) som har integrerat grenar som kan vara färdiga att ingå i grenen next eller master. Iden är att dina genar håller olika nivåer av stabilitet. När de når en mer stabil nivå, slås de samman till grenen ovanför dem. Återigen, att ha flera långlivade grenar är inte nödvändigt, men det är ofta till hjälp när du har att göra med väldigt stora eller komplexa projekt.

Ämnesgrenar är användbara i projekt oavsett storlek. En ämnesgren är en kortlivad gren som du skapar och använder för en enskild specifik funktion eller sammanhängande arbete. Detta är något som du troligen aldrig gjort med något versionshanteringssystem innan eftersom det generellt är dyrt att skapa och slå samman grenar. Men i Git är det vanligt att skapa, arbeta på, slå samman och ta bort grenar flera gånger dagligen.

Du såg detta i förra avsnittet med grenarna iss53 och hotfix som du skapade. Du gjorde några få versioner på dem och tog bort dem direkt efter att de slagits ihop med din huvudgren. Denna teknik tillåter att du byter kontext snabbt och fullständigt — eftersom ditt arbete är separerat i silos där alla ändringar i den grenen har att göra med just den specifika funktionen, är det lättare att se vad som har hänt vid exempelvis kodgranskning. Du kan behålla ändringarna där i minuter, dagar, eller månader, och slå samman dem när de är klara, oaktat ordningen i vilken de skapades eller arbetades på.

Anta exemplet att arbeta lite (på master), grena ut för att lösa ett problem (iss91), jobba lite på den och grena ut igen och försöka lösa problemet på ett annat sätt (iss91v2). Du går sedan tillbaka till master och jobbar där lite och sedan grenar du ut för att göra lite jobb som du inte är säker på är en bra idé (grenen dumbidea). Din versionshistorik kommer se ut något liknande detta:

Anta nu att du vill ha den andra lösningen för problemet (iss91v2) och att du visat grenen dumbidea för dina kollegor och det föreföll sig att den var genial. Du kan då kasta den ordinarie grenen iss91 (och förlora versionerna C5 och C6) samt slå samman de andra två versionerna. Din versionshistorik ser då ut såhär:

Vi kommer gå in i mer detalj gällande olika möjliga arbetsflödena för dit Gitprojekt i Distributed Git, innan du bestämmer dig för vilken förgreningsmodell som ditt nästa projekt skall ha, så glöm inte det kapitlet.

Det är viktigt att komma ihåg att när du gör allt detta, att grenarna är lokala. När du grenar ut och slår ihop grenar görs allt i dit lokala förvar — ingen kommunikation sker med servern.