Teamwork uden forvirring: forståelse af forgreningsstrategier i Git

Introduktion

Git er blevet de facto industristandard for versionskontrolsystemer i softwareudvikling. Du bør først læse min artikel om, hvad Git er , og hvordan du kommer i gang. Har du læst den? Fremragende, lad os komme i gang! Kan du lide det eller ej, dette værktøj skabt af Linus Tovalds går ikke på pension. Så det giver mening at tale om, hvordan distribuerede teams arbejder med Git, og hvilken forgreningsstrategi de skal vælge til dette. Dette er ikke et uvæsentligt spørgsmål. Når man sammensætter et nyt udviklingsteam, som ikke har arbejdet sammen tidligere, er forgreningsstrategien ofte en af ​​de første ting, der skal tages stilling til. Og nogle mennesker vil fråde om munden for at bevise, at én strategi er bedre end en anden. Så jeg vil gerne give dig nogle generelle oplysninger om dem.

Er forgreningsstrategier nødvendige?

De er virkelig nødvendige. Meget nødvendigt. For hvis teamet ikke er enige om noget, så vil hvert teammedlem gøre, hvad han eller hun vil:

• arbejder i hvilken som helst branche
• fusionerer til vilkårlige andre grene
• sletning af nogle grene
• skabe nye
• og så vil hvert teammedlem handle i et uadministreret flow.

Det er derfor, vi har tre strategier at overveje nedenfor. Lad os gå!

GitHub Flow

Denne forgreningsstrategi foretrækkes mærkeligt nok på GitHub :) Den kommer med et sæt regler :

1. Kode i mastergrenen må ikke brydes. Den skal være klar til at blive udrullet til enhver tid. Det vil sige, at du ikke må sætte kode der, som forhindrer dig i at bygge projektet og implementere det på serveren.
2. Når du planlægger at arbejde på ny funktionalitet, skal du oprette en ny funktionsgren baseret på mastergrenen og give den et meningsfuldt navn. Overfør din kode lokalt og skub regelmæssigt dine ændringer til den samme filial i fjernlageret.
3. Åbn en pull request (du kan læse om pull requests her ), når du synes arbejdet er klar og kan flettes ind i mastergrenen (eller hvis du er usikker, men ønsker at få feedback på det udførte arbejde).
4. Efter at den nye funktion i pull-anmodningen er godkendt, kan den flettes ind i mastergrenen.
5. Når ændringerne flettes ind i mastergrenen, bør de implementeres på serveren med det samme.

Ifølge GitHub Flow, før du begynder at arbejde på noget nyt, hvad enten det er en rettelse eller en ny funktion, skal du oprette en ny filial baseret på master og give den et passende navn. Dernæst begynder arbejdet med implementeringen. Du bør konstant indsende commits til fjernserveren med samme navn. Når du konkluderer, at alt er klar, skal du oprette en pull-anmodning til mastergrenen. Så skal mindst én, eller endnu bedre, to personer se på denne kode, før de klikker på "Godkend". Normalt bør projektets teamleder og en anden person helt sikkert tage et kig. Derefter kan du fuldføre pull-anmodningen. GitHub Flow er også kendt for at drive kontinuerlig levering (CD) i projekter. Dette skyldes, at når ændringer går ind i mastergrenen, skal de implementeres på serveren med det samme.

GitFlow

Den tidligere strategi (GitHub Flow) er ikke særlig kompliceret i sin kerne. Der er to typer af grene: master og feature grene. Men GitFlow er mere seriøs. I det mindste burde billedet ovenfor gøre det klart :) Så hvordan fungerer denne strategi? Generelt består GitFlow af to vedvarende grene og flere typer midlertidige grene. I forbindelse med GitHub Flow er mastergrenen vedvarende, og de andre er midlertidige. Vedvarende grene

• mester: Ingen må røre eller skubbe noget til denne gren. I denne strategi repræsenterer master den seneste stabile version, som bruges i produktionen (det vil sige på en rigtig server)
• udvikling: Udviklingsgrenen. Det kan være ustabilt.

Udvikling sker ved hjælp af tre midlertidige hjælpegrene :

1. Funktionsgrene — til udvikling af ny funktionalitet.
2. Udgivelsesgrene — til at forberede udgivelsen af ​​en ny version af projektet.
3. Hotfix-grene - til hurtigt at rette en fejl fundet af rigtige brugere på en rigtig server.

Feature grene

Funktionsgrene er skabt af udviklere til ny funktionalitet. De bør altid oprettes ud fra udviklingsgrenen. Efter at have afsluttet arbejdet med den nye funktionalitet, skal du oprette en pull-anmodning til udviklingsgrenen. Det er klart, at store teams kan have mere end én funktionsgren ad gangen. Tag endnu et kig på billedet i begyndelsen af ​​beskrivelsen af ​​GitFlow-strategien.

Slip grene

Når det nødvendige sæt af nye funktioner er klar i udviklingsgrenen, kan du forberede dig på udgivelsen af ​​en ny version af produktet. En release-gren, som er oprettet med udgangspunkt i udviklingsgrenen, vil hjælpe os med dette. Når du arbejder med udgivelsesgrenen, skal du finde og rette alle fejl. Eventuelle nye ændringer, der er nødvendige for at stabilisere frigivelsesgrenen, skal også flettes tilbage til udviklingsgrenen. Dette gøres for også at stabilisere udviklingsgrenen. Når testere siger, at grenen er stabil nok til en ny udgivelse, flettes den ind i mastergrenen. Senere oprettes et tag, som er tildelt et versionsnummer, til denne commit. For at se et eksempel, se på billedet i begyndelsen af ​​strategien. Der vil du se Tag 1.0— dette er blot et tag, der angiver version 1.0 af projektet. Og endelig har vi hotfix-grenen.

Hotfix filialer

Hotfix-grene er også beregnet til at frigive en ny version til master-grenen. Den eneste forskel er, at disse udgivelser ikke er planlagt. Der er situationer, hvor fejl kommer ind i den frigivne version og opdages i produktionsmiljøet. Tag iOS: Så snart en ny version er frigivet, får du straks en masse opdateringer med rettelser til fejl, der blev fundet efter udgivelsen. Derfor skal vi hurtigt rette en fejl og frigive en ny version. På vores billede svarer dette til version 1.0.1. Tanken er, at arbejdet med ny funktionalitet ikke behøver at stoppe, når det er nødvendigt at rette en fejl på en rigtig server (eller som vi siger, "in prod" eller "in production"). Hotfix-grenen skal oprettes fra master-grenen, da den repræsenterer det, der i øjeblikket kører i produktion. Så snart fejlrettelsen er klar, det flettes til master, og et nyt tag oprettes. Ligesom at forberede en udgivelsesgren, bør en hotfix-gren også flette sin rettelse tilbage til udviklingsgrenen.

Forking workflow

I forking workflowet involverer udvikling to repositories:

1. Det originale lager, som alle ændringer vil blive flettet ind i.
2. Et gaffellager. Dette er en kopi af det originale lager, der ejes af en anden udvikler, der ønsker at foretage ændringer til originalen.

Det lyder lidt mærkeligt indtil videre, ikke? Enhver, der allerede har stødt på open source-udvikling, kender allerede denne tilgang. Denne strategi giver følgende fordel: udvikling kan ske i et gaffellager uden at give tilladelser til fælles udvikling i den oprindelige filial. Ejeren af ​​det oprindelige depot har naturligvis ret til at afvise de foreslåede ændringer. Eller at acceptere og fusionere dem. Dette er praktisk for både ejeren af ​​det originale lager og udvikleren, der ønsker at hjælpe med at skabe produktet. For eksempel kan du foreslå ændringer til Linux-kernen . Hvis Linus beslutter, at de giver mening, vil ændringerne blive tilføjet (!!!).

Et eksempel på gaffelarbejdsgangen

Forking workflowet anvendes på GitHub, når der er et bibliotek, du vil bruge. Den har en fejl, der forhindrer dig i at bruge den fuldt ud. Antag, at du dykker dybt nok ned i problemet og kender løsningen. Ved at bruge forking-workflowet kan du løse problemet uden rettigheder til at arbejde i bibliotekets originale lager. For at komme i gang skal du vælge et eller andet lager, for eksempel Spring Framework . Find og klik på knappen "Fork" i øverste højre hjørne: Dette vil tage noget tid. Derefter vises en kopi af det originale lager på din personlige konto, hvilket vil indikere, at det er en gaffel:Nu kan du arbejde med dette lager som sædvanligt, tilføje ændringer til mastergrenen, og når alt er klar, kan du oprette en pull-anmodning til det originale lager. For at gøre dette skal du klikke på knappen Ny pull request :

Hvilken strategi skal man vælge

Git er et fleksibelt og kraftfuldt værktøj, der lader dig arbejde ved hjælp af en bred vifte af processer og strategier. Men jo flere valgmuligheder du har, jo sværere er det at beslutte, hvilken strategi du skal vælge. Det er klart, at der ikke er et enkelt svar for alle. Alt afhænger af situationen. Når det er sagt, er der flere retningslinjer, der kan hjælpe med dette:

1. Det er bedst at vælge den enkleste strategi først. Gå kun til mere komplekse strategier, når det er nødvendigt.
2. Overvej strategier, der har så få filialtyper som muligt for udviklere.
3. Se på fordele og ulemper ved de forskellige strategier, og vælg derefter den, du skal bruge til dit projekt.

Det var alt, hvad jeg ville sige om forgreningsstrategier i Git. Tak for din opmærksomhed :) Følg mig på GitHub , hvor jeg ofte poster mine kreationer, der involverer forskellige teknologier og værktøjer, som jeg bruger i mit arbejde.