Git tilbyder fleksible forgreningsstrategier, men hvad betyder det? Med enkle ord er en forgreningsstrategi et sæt regler, en konvention, der hjælper teams og udviklere – de kan følge disse regler og konventioner for at skabe en ny filial, dens flow osv.
Manglende brug af passende navnekonventioner fører til forvirring og komplicerer kodevedligeholdelsesteamet. Vi kan ikke ignorere Git's bedste praksis inden for forgrenede navnekonventioner.
Git-forgreningsstrategier tillader adskillelse af arbejdet. Overordnet set kan vi opdele Git-grene i to kategorier:almindelige og midlertidige filialer.
Almindelige Git-grene
Disse filialer vil være tilgængelige i dit lager på permanent basis. Deres navnekonvention er enkel og ligetil.
- Udvikling (dev ) er den vigtigste udviklingsgren. Dev-grenens idé er at foretage ændringer i den og begrænse udviklerne fra at foretage ændringer i master-grenen direkte. Ændringer i dev-grenen gennemgås og, efter test, fusioneres med master-grenen.
- Mester (mester ) er standardgrenen tilgængelig i Git-lageret. Det skal være stabilt hele tiden og tillader ikke nogen direkte check-in. Du kan kun flette den efter kodegennemgang. Alle teammedlemmer er ansvarlige for at holde masteren stabil og opdateret.
- QA (QA ), eller testgren, indeholder al koden til QA-test og automatiseringstest af alle implementerede ændringer. Før en ændring går til produktionsmiljøet, skal det gennemgå QA-testen for at få en stabil kodebase.
Midlertidige Git-grene
Som navnet indikerer, er det de grene, der kan oprettes og slettes efter behov. De kan være som følger:
- Fejlrettelse
- Hot rettelse
- Funktionsgrene
- Eksperimentelle grene
- WIP-grene
Der er mange formater og navnekonventioner anbefalet af eksperter til midlertidige filialer.
Her er en simpel arbejdsgang af Git-grene.
Git Branching Navnekonvention
I denne artikel vil jeg gennemgå og dele de syv bedste navnekonventioner, som jeg brugte personligt i fortiden for at sikre deres effektivitet.
1. Start filialnavnet med et gruppeord
Det er en af de bedste praksisser. Gruppeordet kan være hvad som helst, der matcher din arbejdsgang.
Jeg kan godt lide korte ord som følgende:
Bug – Fejlen, som snart skal rettes
WIP – Arbejdet er i gang, og jeg er klar over, at det ikke afsluttes snart
Ved at se på filialnavnet kan du forstå, hvad denne Git-gren handler om og dens formål.
Tag et kig på nedenstående eksempler:
- bug-logo-alignment-issue – udvikleren forsøger at løse problemet med logojusteringen;
- wip-ioc-container-added – grenen relaterer sig til opgaven med at tilføje en IoC-beholder i gang.
2. Brug Unikt ID i filialnavne
Du kan bruge issue tracker-id'et i dit filialnavn. Jeg foretrækker denne metode, når jeg arbejder på at rette nogle fejl. For eksempel:
wip-8712-add-testing-module
Navnet viser, at grenen gælder for opgaven med at tilføje et testmodul, sporings-id'et for problemet er 8712, og arbejdet er i gang.
En yderligere fordel ved at bruge et eksternt sporings-id i filialnavnet er muligheden for at spore fremskridtene fra et eksternt system.
3. Brug bindestreg eller skråstreg som skilletegn
Mange udviklere bruger skråstreg som en separator, og mange bruger bindestreger. Hvilken man skal bruge – afhænger af dig og dit teams præferencer.
Min mening er, at bindestreger gør navnet mere behageligt at læse, så det er en passende separator i grennavne. Du kan bruge skråstreger, bindestreger og understregninger. Pointen er at være konsekvent.
Der er to hovedfordele ved at bruge en separator i filialnavnet:
- Det øger læsbarheden og hjælper med at undgå forvirring;
- Det gør det nemmere at administrere, især hvis du har med mange filialer at gøre.
Eksempel 1. Git grennavn uden nogen separator:
featureupgradejqueryversionloginmodule
Eksempel 2. Ved at tilføje en separator (i dette tilfælde er det en understregning), gør du Git-grennavnet læsbart:
feature_upgrade_jquery_version_login_module
4. Git-gren med forfatternavn
Mange virksomheder foretrækker at tilføje forfatternavne i filialnavnene i henhold til formatet nedenfor:
<author>_<branch-type>_<branch-name>F.eks. rajeev.bera_feature_new-experimental-changes
Denne metode giver mulighed for let sporing af forskellige udvikleres arbejde og fremskridt med yderligere systemer.
5. Undgå kun at bruge tal
Nogle udviklere bruger kun problem-id'et i filialnavnet, hvilket ikke er nyttigt i arbejdets fremskridt.
For eksempel er der et filialnavn 9912 – hvad skal dette magiske tal fortælle os? Det betyder kun mere forvirring og risiko for fejl, især under sammensmeltning med andre git-grene.
6. Undgå at bruge al navngivningskonvention samtidigt
At blande og matche alle Git-grennavnekonventioner er ikke den bedste praksis. Det tilføjer kun forvirring og komplicerer de overordnede processer.
Et team bør beslutte, hvilke navnekonventioner der skal bruges i arbejdet én gang og holde sig til dem. Konsistens er det mest kritiske.
7. Undgå lange beskrivende navne for langlivede grene
Den væsentlige kvalitet ved et filialnavn er, at det skal være præcist og informativt. Lad os se på nogle eksempler igen:
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Der er filialnavnene lange og detaljerede. Det er ikke nødvendigt. I stedet kan du bruge følgende variant:
wip_feature_login_module
Dette navn er kort, men det forklarer formålet med denne gren.
Konklusion
Git-forgreningsmodellen er kraftfuld, men du skal styre grenene korrekt og effektivt. En af de nødvendige faktorer er at følge de samme konventioner af alle teams, især – navnekonventionerne for det lokale lager.
For at sikre, at dit team bruger de aftalte konventioner, skal du håndhæve standarderne. En af de nemmeste måder er at bruge Git hooks, som pre-commit hook. Jeg håber, det vil give dig en idé om Git-forgreningsmodellerne og deres navnekonvention.