Git biedt flexibele vertakkingsstrategieën, maar wat betekent het? In eenvoudige bewoordingen is een vertakkingsstrategie een reeks regels, een conventie die teams en ontwikkelaars helpt - ze kunnen deze regels en conventies volgen om een nieuwe vertakking, de stroom ervan, enz. te creëren.
Het niet gebruiken van de juiste naamgevingsconventies leidt tot verwarring en compliceert het code-onderhoudsteam. We kunnen Git best practices in het vertakken van naamconventies niet negeren.
Git-vertakkingsstrategieën maken scheiding van werk mogelijk. In grote lijnen kunnen we Git-takken in twee categorieën verdelen:reguliere en tijdelijke takken.
Regelmatige Git-takken
Deze vestigingen zullen permanent beschikbaar zijn in uw repository. Hun naamgeving is eenvoudig en duidelijk.
- Ontwikkeling (dev ) is de belangrijkste ontwikkelingstak. Het idee van de dev-branch is om er wijzigingen in aan te brengen en de ontwikkelaars te beperken om rechtstreeks wijzigingen in de master-branch aan te brengen. Veranderingen in de dev branch ondergaan reviews en worden, na testen, samengevoegd met de master branch.
- Meester (meester ) is de standaard branch die beschikbaar is in de Git-repository. Het moet altijd stabiel zijn en laat geen directe check-in toe. Je kunt het alleen samenvoegen na codebeoordeling. Alle teamleden zijn verantwoordelijk voor het stabiel en up-to-date houden van de master.
- QA (QA ), of test branch, bevat alle code voor QA-testen en automatiseringstests van alle geïmplementeerde wijzigingen. Voordat een wijziging naar de productieomgeving gaat, moet deze de QA-test ondergaan om een stabiele codebase te krijgen.
Tijdelijke Git-takken
Zoals de naam al aangeeft, zijn dit de takken die kunnen worden gemaakt en verwijderd wanneer dat nodig is. Ze kunnen als volgt zijn:
- Bugfix
- Hotfix
- Functietakken
- Experimentele takken
- WIP-filialen
Er zijn veel formaten en naamgevingsconventies die door experts worden aanbevolen voor tijdelijke branches.
Hier is een eenvoudige workflow van Git branches.
Git Branching-naamgevingsconventie
In dit artikel zal ik de zeven beste naamgevingsconventies bespreken en delen die ik in het verleden persoonlijk heb gebruikt om hun efficiëntie te garanderen.
1. Vertakkingsnaam starten met een groepswoord
Het is een van de best practices. Het groepswoord kan van alles zijn dat bij uw workflow past.
Ik hou van korte woorden zoals de volgende:
Bug – De bug die binnenkort moet worden opgelost
WIP – Het werk is in uitvoering en ik ben me ervan bewust dat het niet snel klaar zal zijn
Door naar de branchnaam te kijken, kun je begrijpen waar deze Git branch over gaat en wat het doel ervan is.
Bekijk de onderstaande voorbeelden:
- bug-logo-alignment-issue – de ontwikkelaar probeert het probleem met de uitlijning van het logo op te lossen;
- wip-ioc-container-added – de vertakking heeft betrekking op de taak om een IoC-container in uitvoering toe te voegen.
2. Gebruik unieke ID in filiaalnamen
U kunt de issue tracker-ID in uw filiaalnaam gebruiken. Ik geef de voorkeur aan deze methode wanneer ik werk aan het oplossen van enkele bugs. Bijvoorbeeld:
wip-8712-add-testing-module
De naam laat zien dat de tak van toepassing is op de taak om een testmodule toe te voegen, de tracking-ID van het probleem is 8712 en het werk is in uitvoering.
Nog een voordeel van het gebruik van een externe tracking-ID in de filiaalnaam is de mogelijkheid om de voortgang van een extern systeem te volgen.
3. Gebruik koppelteken of schuine streep als scheidingstekens
Veel ontwikkelaars gebruiken een schuine streep als scheidingsteken en velen gebruiken koppeltekens. Welke je moet gebruiken, hangt af van jou en de voorkeuren van je team.
Mijn mening is dat koppeltekens de naam prettiger leesbaar maken, dus het is een geschikt scheidingsteken in namen van takken. U kunt slashes, koppeltekens en underscores gebruiken. Het punt is om consistent te zijn.
Er zijn twee belangrijke voordelen van het gebruik van een scheidingsteken in de naam van de vertakking:
- Het verhoogt de leesbaarheid en helpt verwarring te voorkomen;
- Het maakt het gemakkelijker te beheren, vooral als je met veel filialen te maken hebt.
Voorbeeld 1. Git-taknaam zonder scheidingsteken:
featureupgradejqueryversionloginmodule
Voorbeeld 2. Door een scheidingsteken toe te voegen (in dit geval is het een onderstrepingsteken), maakt u de Git-taknaam leesbaar:
feature_upgrade_jquery_version_login_module
4. Git Branch met naam van de auteur
Veel bedrijven geven er de voorkeur aan auteursnamen toe te voegen aan de branchenamen volgens het onderstaande formaat:
<author>_<branch-type>_<branch-name>Bijvoorbeeld rajeev.bera_feature_new-experimental-changes
Deze methode maakt het mogelijk om het werk en de voortgang van verschillende ontwikkelaars eenvoudig te volgen met extra systemen.
5. Vermijd het gebruik van alleen cijfers
Sommige ontwikkelaars gebruiken alleen de issue-ID in de naam van het filiaal, wat niet helpt bij de voortgang van het werk.
Er is bijvoorbeeld een filiaalnaam 9912 - wat moet dit magische nummer ons vertellen? Het betekent alleen maar meer verwarring en risico op fouten, vooral tijdens het samenvoegen met andere git branches.
6. Vermijd het gelijktijdig gebruiken van alle naamconventies
Het mixen en matchen van alle Git branch naamgevingsconventies is niet de beste gewoonte. Het voegt alleen maar verwarring toe en bemoeilijkt de algehele processen.
Een team moet beslissen welke naamgevingsconventies ze één keer in het werk moeten gebruiken, en zich eraan houden. Consistentie is het belangrijkste.
7. Vermijd lange beschrijvende namen voor langlevende takken
De essentiële kwaliteit van een branchenaam is dat deze nauwkeurig en informatief moet zijn. Laten we nog eens naar enkele voorbeelden kijken:
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Daar zijn de namen van de takken lang en gedetailleerd. Het is niet noodzakelijk. In plaats daarvan kunt u de volgende variant gebruiken:
wip_feature_login_module
Deze naam is kort, maar het verklaart het doel van deze tak.
Conclusie
Het Git-vertakkingsmodel is krachtig, maar u moet de vertakkingen correct en effectief beheren. Een van de noodzakelijke factoren is het volgen van dezelfde conventies door alle teams, met name de naamgevingsconventies voor de lokale repository.
Om ervoor te zorgen dat uw team de overeengekomen conventies gebruikt, moet u de normen handhaven. Een van de gemakkelijkste manieren is om Git hooks te gebruiken, zoals de pre-commit hook. Ik hoop dat het je een idee geeft over de Git-vertakkingsmodellen en hun naamgevingsconventie.