Teamwerk zonder verwarring: vertakkingsstrategieën in Git begrijpen

Invoering

Git is de de facto industriestandaard geworden voor versiebeheersystemen bij softwareontwikkeling. Lees eerst mijn artikel over wat Git is en hoe je aan de slag kunt. Heb je het gelezen? Uitstekend, laten we gaan! Of je het nu leuk vindt of niet, deze tool gemaakt door Linus Tovalds gaat niet met pensioen. Het is dus logisch om te praten over hoe gedistribueerde teams met Git werken en welke vertakkingsstrategie ze hiervoor moeten kiezen. Dit is geen onbelangrijke vraag. Bij het samenstellen van een nieuw ontwikkelteam dat nog niet eerder heeft samengewerkt, is de vertakkingsstrategie vaak een van de eerste dingen die moeten worden beslist. En sommige mensen zullen het schuim op de mond lopen om te bewijzen dat de ene strategie beter is dan de andere. Daarom wil ik u wat algemene informatie over hen geven.

Zijn vertakkingsstrategieën nodig?

Die zijn inderdaad nodig. Erg nodig. Want als het team het ergens niet over eens is, dan doet ieder teamlid wat hij of zij wil:

• werken in welke branche dan ook
• opgaan in willekeurige andere takken
• enkele takken verwijderen
• nieuwe creëren
• en dus zal elk teamlid handelen in een onbeheerde stroom.

Daarom hebben we hieronder drie strategieën om te overwegen. Laten we gaan!

GitHub-stroom

Deze vertakkingsstrategie heeft, vreemd genoeg, de voorkeur op GitHub :) Het wordt geleverd met een reeks regels :

1. Code in de master branch mag niet gebroken worden. Het moet op elk moment klaar zijn om te worden ingezet. Dat wil zeggen, u mag daar geen code plaatsen die u ervan weerhoudt het project te bouwen en op de server te implementeren.
2. Wanneer u van plan bent om aan nieuwe functionaliteit te werken, moet u een nieuwe feature branch maken op basis van de master branch en deze een betekenisvolle naam geven. Leg uw code lokaal vast en push uw wijzigingen regelmatig naar dezelfde branch in de externe repository.
3. Open een pull-request (u kunt hier over pull-requests lezen ) wanneer u denkt dat het werk klaar is en kan worden samengevoegd in de master-branch (of als u het niet zeker weet, maar feedback wilt krijgen over het uitgevoerde werk).
4. Nadat de nieuwe functie in het pull-verzoek is goedgekeurd, kan deze worden samengevoegd in de master-branch.
5. Wanneer de wijzigingen zijn samengevoegd in de master-branch, moeten ze onmiddellijk op de server worden geïmplementeerd.

Volgens GitHub Flow moet je, voordat je aan iets nieuws gaat werken, of het nu een fix of een nieuwe functie is, een nieuwe branch maken op basis van master en deze een geschikte naam geven. Daarna begint het werk aan de implementatie. Je moet constant commits indienen bij de externe server met dezelfde naam. Als je concludeert dat alles klaar is, moet je een pull request naar de master branch maken. Dan moeten minstens één, of beter nog, twee mensen naar deze code kijken voordat ze op "Goedkeuren" klikken. Meestal moeten de teamleider van het project en een tweede persoon zeker een kijkje nemen. Vervolgens kunt u het pull-verzoek voltooien. GitHub Flow staat ook bekend om het stimuleren van continuous delivery (CD) in projecten. Dit komt omdat wanneer wijzigingen naar de master branch gaan, deze onmiddellijk naar de server moeten worden geïmplementeerd.

GitFlow

De vorige strategie (GitHub Flow) is in de kern niet erg ingewikkeld. Er zijn twee soorten branches: master en feature branches. Maar GitFlow is serieuzer. Althans, de foto hierboven zou dat duidelijk moeten maken :) Dus hoe werkt deze strategie? Over het algemeen bestaat GitFlow uit twee persistente branches en verschillende soorten tijdelijke branches. In de context van GitHub Flow is de master branch persistent en de andere zijn tijdelijk. Hardnekkige takken

• meester: Niemand mag iets aanraken of naar deze tak duwen. In deze strategie vertegenwoordigt master de nieuwste stabiele versie, die wordt gebruikt in productie (dat wil zeggen op een echte server)
• ontwikkeling: De ontwikkelingstak. Het kan instabiel zijn.

De ontwikkeling gebeurt met behulp van drie tijdelijke hulptakken :

1. Feature branches — voor het ontwikkelen van nieuwe functionaliteit.
2. Branches vrijgeven — ter voorbereiding op de release van een nieuwe versie van het project.
3. Hotfix branches — voor het snel repareren van een bug die door echte gebruikers op een echte server is gevonden.

Feature takken

Functietakken worden door ontwikkelaars gemaakt voor nieuwe functionaliteit. Ze moeten altijd worden gemaakt op basis van de ontwikkelingstak. Nadat u het werk aan de nieuwe functionaliteit hebt voltooid, moet u een pull-aanvraag maken voor de ontwikkelingstak. Het is duidelijk dat grote teams meer dan één functietak tegelijk kunnen hebben. Kijk nog eens naar de afbeelding aan het begin van de beschrijving van de GitFlow-strategie.

Takken vrijgeven

Wanneer de vereiste set nieuwe functies gereed is in de ontwikkelingstak, kunt u zich voorbereiden op de release van een nieuwe versie van het product. Een release branch, die is gemaakt op basis van de development branch, zal ons hierbij helpen. Als je met de release branch werkt, moet je alle bugs vinden en oplossen. Alle nieuwe wijzigingen die nodig zijn om de release-tak te stabiliseren, moeten ook weer worden samengevoegd in de ontwikkelingstak. Dit wordt gedaan om ook de ontwikkelingstak te stabiliseren. Wanneer testers zeggen dat de branch stabiel genoeg is voor een nieuwe release, wordt deze gemerged in de master branch. Later wordt voor deze commit een tag gemaakt, waaraan een versienummer is toegewezen. Om een ​​voorbeeld te zien, kijk naar de afbeelding aan het begin van de strategie. Daar zie je Tag 1.0— dit is slechts een tag die versie 1.0 van het project aangeeft. En tot slot hebben we de hotfix-tak.

Hotfix-takken

Hotfix branches zijn ook bedoeld voor het vrijgeven van een nieuwe versie aan de master branch. Het enige verschil is dat die releases niet gepland zijn. Er zijn situaties waarin bugs in de uitgebrachte versie terechtkomen en worden ontdekt in de productieomgeving. Neem iOS: zodra er een nieuwe versie uitkomt, krijg je meteen een heleboel updates met fixes voor bugs die na de release zijn gevonden. Daarom moeten we snel een bug oplossen en een nieuwe versie uitbrengen. In ons plaatje komt dit overeen met versie 1.0.1. Het idee is dat het werken aan nieuwe functionaliteit niet hoeft te stoppen wanneer het nodig is om een ​​bug op een echte server te repareren (of zoals we zeggen, "in prod" of "in productie"). De hotfix-branch moet worden gemaakt vanuit de master-branch, omdat deze vertegenwoordigt wat er momenteel in productie wordt uitgevoerd. Zodra de bugfix klaar is, het wordt samengevoegd in de master en er wordt een nieuwe tag gemaakt. Net als bij het voorbereiden van een release-branch, zou een hotfix-branch ook zijn fix moeten samenvoegen met de development-branch.

Workflow voor vorken

In de forking-workflow omvat de ontwikkeling twee opslagplaatsen:

1. De oorspronkelijke repository, waarin alle wijzigingen worden samengevoegd.
2. Een fork-repository. Dit is een kopie van de originele repository, eigendom van een andere ontwikkelaar die wijzigingen wil aanbrengen in het origineel.

Klinkt tot nu toe een beetje vreemd, toch? Iedereen die al met open source development in aanraking is gekomen, kent deze aanpak al. Deze strategie heeft het volgende voordeel: ontwikkeling kan plaatsvinden in een fork-repository zonder machtigingen te verlenen voor gezamenlijke ontwikkeling in de oorspronkelijke branch. Uiteraard heeft de eigenaar van de oorspronkelijke repository het recht om de voorgestelde wijzigingen af ​​te wijzen. Of om ze te accepteren en samen te voegen. Dit is handig voor zowel de eigenaar van de oorspronkelijke repository als de ontwikkelaar die wil helpen bij het maken van het product. U kunt bijvoorbeeld wijzigingen in de Linux-kernel voorstellen . Als Linus besluit dat ze zinvol zijn, worden de wijzigingen toegevoegd (!!!).

Een voorbeeld van de forking-workflow

De forking-workflow wordt toegepast op GitHub wanneer er een bibliotheek is die u wilt gebruiken. Het heeft een bug waardoor je het niet volledig kunt gebruiken. Stel dat je diep genoeg in het probleem duikt en de oplossing kent. Met behulp van de forking-workflow kunt u het probleem oplossen zonder rechten om in de oorspronkelijke repository van de bibliotheek te werken. Om aan de slag te gaan, moet u een bepaalde repository selecteren, bijvoorbeeld het Spring Framework . Zoek en klik op de knop "Fork" in de rechterbovenhoek: dit zal enige tijd duren. Vervolgens verschijnt er een kopie van de originele repository in uw persoonlijke account, wat aangeeft dat het een fork is:Nu kun je zoals gewoonlijk met deze repository werken, wijzigingen toevoegen aan de master -branch, en als alles klaar is, kun je een pull-verzoek naar de originele repository maken. Om dit te doen, klikt u op de knop Nieuw pull-verzoek :

Welke strategie te kiezen

Git is een flexibele en krachtige tool waarmee je kunt werken met een breed scala aan processen en strategieën. Maar hoe meer keuzes je hebt, hoe moeilijker het is om te beslissen welke strategie je moet kiezen. Het is duidelijk dat er geen eenduidig ​​antwoord is voor iedereen. Alles hangt af van de situatie. Dat gezegd hebbende, zijn er verschillende richtlijnen die hierbij kunnen helpen:

1. Het is het beste om eerst de eenvoudigste strategie te kiezen. Ga alleen naar complexere strategieën wanneer dat nodig is.
2. Overweeg strategieën die voor ontwikkelaars zo min mogelijk branchetypen hebben.
3. Bekijk de voor- en nadelen van de verschillende strategieën en kies vervolgens de strategie die u nodig heeft voor uw project.

Dat is alles wat ik wilde zeggen over vertakkingsstrategieën in Git. Bedankt voor je aandacht :) Volg mij op GitHub , waar ik vaak mijn creaties plaats met verschillende technologieën en tools die ik in mijn werk gebruik.