Git erbjuder flexibla förgreningsstrategier, men vad betyder det? Med enkla ord är en grenstrategi en uppsättning regler, en konvention som hjälper team och utvecklare – de kan följa dessa regler och konventioner för att skapa en ny gren, dess flöde, etc.
Att inte använda lämpliga namnkonventioner leder till förvirring och komplicerar kodunderhållsteamet. Vi kan inte ignorera Gits bästa praxis för förgrenade namnkonventioner.
Git-förgreningsstrategier tillåter separation av arbete. I stora drag kan vi dela in Git-grenar i två kategorier:ordinarie och tillfälliga grenar.
Vanliga Git-grenar
Dessa grenar kommer att vara tillgängliga i ditt arkiv på permanent bas. Deras namnkonvention är enkel och okomplicerad.
- Utveckling (dev ) är den huvudsakliga utvecklingsgrenen. Utvecklargrenens idé är att göra ändringar i den och begränsa utvecklarna från att göra några ändringar i huvudgrenen direkt. Ändringar i utvecklargrenen genomgår granskningar och, efter testning, slås de samman med huvudgrenen.
- Master (master ) är standardgrenen tillgänglig i Git-förvaret. Det ska vara stabilt hela tiden och tillåter inte någon direkt incheckning. Du kan bara slå ihop det efter kodgranskning. Alla teammedlemmar är ansvariga för att hålla mastern stabil och uppdaterad.
- QA (QA ), eller testgren, innehåller all kod för QA-testning och automationstestning av alla implementerade ändringar. Innan någon förändring går till produktionsmiljön måste den genomgå QA-testning för att få en stabil kodbas.
Tillfälliga Git-grenar
Som namnet indikerar är dessa grenar som kan skapas och tas bort vid behov. De kan vara följande:
- Bugfix
- Hot Fix
- Funktionsgrenar
- Experimentella grenar
- WIP-grenar
Det finns många format och namnkonventioner som rekommenderas av experter för tillfälliga filialer.
Här är ett enkelt arbetsflöde av Git-grenar.
Git Branching Naming Convention
I den här artikeln kommer jag att granska och dela de sju bästa namnkonventionerna som jag använde personligen tidigare för att säkerställa deras effektivitet.
1. Börja filialnamnet med ett gruppord
Det är en av de bästa metoderna. Gruppordet kan vara vad som helst för att matcha ditt arbetsflöde.
Jag gillar korta ord som följande:
Bug – Felet som måste åtgärdas snart
WIP – Arbetet pågår och jag är medveten om att det inte kommer att slutföras snart
Genom att titta på filialnamnet kan du förstå vad den här Git-grenen handlar om och dess syfte.
Ta en titt på exemplen nedan:
- bug-logo-alignment-issue – utvecklaren försöker fixa problemet med logotypjusteringen;
- wip-ioc-container-added – grenen relaterar till uppgiften att lägga till en pågående IoC-behållare.
2. Använd unikt ID i filialnamn
Du kan använda issue tracker-ID i ditt filialnamn. Jag föredrar den här metoden när jag arbetar med att fixa vissa buggar. Till exempel:
wip-8712-add-testing-module
Namnet visar att grenen gäller uppgiften att lägga till en testmodul, problemets spårnings-ID är 8712 och arbetet pågår.
Ytterligare en fördel med att använda ett externt spårnings-ID i filialnamnet är möjligheten att spåra framstegen från ett externt system.
3. Använd bindestreck eller snedstreck som avgränsare
Många utvecklare använder snedstreck som avgränsare, och många använder bindestreck. Vilken du ska använda – beror på dig och ditt teams preferenser.
Min åsikt är att bindestreck gör namnet mer bekvämt att läsa, så det är en lämplig avgränsare i grennamn. Du kan använda snedstreck, bindestreck och understreck. Poängen är att vara konsekvent.
Det finns två huvudsakliga fördelar med att använda en separator i filialnamnet:
- Det ökar läsbarheten och hjälper till att undvika förvirring;
- Det gör det lättare att hantera, särskilt om du har att göra med många grenar.
Exempel 1. Git grennamn utan någon separator:
featureupgradejqueryversionloginmodule
Exempel 2. Genom att lägga till en separator (i det här fallet är det ett understreck) gör du Git-grennamnet läsbart:
feature_upgrade_jquery_version_login_module
4. Git-gren med författarens namn
Många företag föredrar att lägga till författares namn i filialnamnen enligt formatet nedan:
<author>_<branch-type>_<branch-name>T.ex. rajeev.bera_feature_new-experimental-changes
Denna metod möjliggör enkel spårning av olika utvecklares arbete och framsteg med ytterligare system.
5. Undvik att endast använda siffror
Vissa utvecklare använder bara problemets ID i filialnamnet, vilket inte är till hjälp för arbetets framsteg.
Det finns till exempel ett filialnamn 9912 – vad ska detta magiska nummer säga oss? Det betyder bara mer förvirring och risk för misstag, speciellt vid sammanslagning med andra git-grenar.
6. Undvik att använda alla namnkonventioner samtidigt
Att blanda och matcha alla namnkonventioner för Git-grenar är inte den bästa praxisen. Det skapar bara förvirring och komplicerar de övergripande processerna.
Ett team bör en gång bestämma vilka namnkonventioner som ska användas i arbetet och hålla sig till dem. Konsekvens är det mest kritiska.
7. Undvik långa beskrivande namn för långlivade grenar
Den väsentliga egenskapen hos ett filialnamn är att det ska vara exakt och informativt. Låt oss ta en titt på några exempel igen:
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Där är filialnamnen långa och detaljerade. Det är inte nödvändigt. Istället kan du använda följande variant:
wip_feature_login_module
Detta namn är kort, men det förklarar syftet med denna gren.
Slutsats
Git-förgreningsmodellen är kraftfull, men du måste hantera grenarna korrekt och effektivt. En av de nödvändiga faktorerna är att följa samma konventioner av alla team, särskilt – namnkonventionerna för det lokala förvaret.
För att se till att ditt team använder de överenskomna konventionerna, upprätthåll standarderna. Ett av de enklaste sätten är att använda Git-krokar, som pre-commit-kroken. Jag hoppas att det kommer att ge dig en uppfattning om Git-förgreningsmodellerna och deras namnkonvention.