Teamarbeid uten forvirring: forstå forgreningsstrategier i Git

Introduksjon

Git har blitt de facto industristandarden for versjonskontrollsystemer i programvareutvikling. Du bør først lese artikkelen min om hva Git er og hvordan du kommer i gang. Har du lest den? Utmerket, la oss komme i gang! Liker det eller ikke, dette verktøyet laget av Linus Tovalds kommer ikke til å pensjonere seg. Så det er fornuftig å snakke om hvordan distribuerte team jobber med Git og hvilken forgreningsstrategi de bør velge for dette. Dette er ikke et uvesentlig spørsmål. Når du setter sammen et nytt utviklingsteam som ikke har jobbet sammen tidligere, er forgreningsstrategien ofte noe av det første som skal bestemmes. Og noen mennesker vil skumme for å bevise at en strategi er bedre enn en annen. Så jeg ønsker å formidle litt generell informasjon om dem.

Er det nødvendig med forgreningsstrategier?

De er virkelig nødvendige. Veldig nødvendig. For hvis teamet ikke blir enige om noe, vil hvert teammedlem gjøre hva han eller hun vil:

• jobber i hvilken som helst gren
• smelter sammen til vilkårlige andre grener
• sletter noen grener
• skape nye
• og så vil hvert teammedlem handle i en uadministrert flyt.

Det er derfor vi har tre strategier å vurdere nedenfor. La oss gå!

GitHub Flow

Denne forgreningsstrategien er merkelig nok foretrukket på GitHub :) Den kommer med et sett med regler :

1. Kode i mastergrenen må ikke brytes. Den skal være klar til å bli distribuert når som helst. Det vil si at du ikke må legge kode der som vil hindre deg i å bygge prosjektet og distribuere det til serveren.
2. Når du planlegger å jobbe med ny funksjonalitet, må du opprette en ny funksjonsgren basert på hovedgrenen og gi den et meningsfylt navn. Overfør koden din lokalt og skyv regelmessig endringene til den samme grenen i det eksterne depotet.
3. Åpne en pull request (du kan lese om pull requests her ) når du mener arbeidet er klart og kan slås sammen i mastergrenen (eller hvis du er usikker, men ønsker å få tilbakemelding på arbeidet som er utført).
4. Etter at den nye funksjonen i pull-forespørselen er godkjent, kan den flettes inn i mastergrenen.
5. Når endringene er slått sammen til hovedgrenen, bør de distribueres til serveren umiddelbart.

I følge GitHub Flow, før du begynner å jobbe med noe nytt, enten det er en fiksering eller en ny funksjon, må du opprette en ny gren basert på master og gi den et passende navn. Deretter starter arbeidet med implementeringen. Du bør hele tiden sende inn forpliktelser til den eksterne serveren med samme navn. Når du konkluderer med at alt er klart, må du opprette en pull-forespørsel til mastergrenen. Da bør minst én, eller enda bedre, to personer se på denne koden før de klikker på "Godkjenn". Vanligvis bør prosjektlederen og en annen person definitivt ta en titt. Deretter kan du fullføre pull-forespørselen. GitHub Flow er også kjent for å drive kontinuerlig levering (CD) i prosjekter. Dette er fordi når endringer går inn i hovedgrenen, bør de distribueres til serveren umiddelbart.

GitFlow

Den forrige strategien (GitHub Flow) er ikke veldig komplisert i kjernen. Det finnes to typer grener: master- og funksjonsgrener. Men GitFlow er mer seriøs. Bildet ovenfor burde i det minste gjøre det klart :) Så hvordan fungerer denne strategien? Generelt består GitFlow av to vedvarende grener og flere typer midlertidige grener. I sammenheng med GitHub Flow er mastergrenen vedvarende og de andre er midlertidige. Vedvarende grener

• mester: Ingen skal røre eller dytte noe til denne grenen. I denne strategien representerer master den siste stabile versjonen, som brukes i produksjon (det vil si på en ekte server)
• utvikling: Utviklingsgrenen. Det kan være ustabilt.

Utvikling skjer ved hjelp av tre midlertidige hjelpegrener :

1. Funksjonsgrener – for å utvikle ny funksjonalitet.
2. Utgivelsesgrener — for å forberede utgivelsen av en ny versjon av prosjektet.
3. Hurtigreparasjonsgrener – for raskt å fikse en feil funnet av ekte brukere på en ekte server.

Funksjonsgrener

Funksjonsgrener er laget av utviklere for ny funksjonalitet. De skal alltid opprettes basert på utviklingsgrenen. Etter å ha fullført arbeidet med den nye funksjonaliteten, må du opprette en pull-forespørsel til utviklingsgrenen. Det er klart at store team kan ha mer enn én funksjonsgren om gangen. Ta en ny titt på bildet i begynnelsen av beskrivelsen av GitFlow-strategien.

Slipp grener

Når det nødvendige settet med nye funksjoner er klart i utviklingsgrenen, kan du forberede utgivelsen av en ny versjon av produktet. En utgivelsesgren, som er opprettet basert på utviklingsgrenen, vil hjelpe oss med dette. Når du arbeider med utgivelsesgrenen, må du finne og fikse alle feil. Eventuelle nye endringer som kreves for å stabilisere frigjøringsgrenen må også slås sammen tilbake til utviklingsgrenen. Dette gjøres for å stabilisere utviklingsgrenen også. Når testere sier at grenen er stabil nok for en ny utgivelse, blir den slått sammen til hovedgrenen. Senere opprettes en tag, som er tildelt et versjonsnummer, for denne commit. For å se et eksempel, se på bildet i begynnelsen av strategien. Der vil du se Tag 1.0— dette er bare en kode som indikerer versjon 1.0 av prosjektet. Og til slutt har vi hurtigreparasjonsfilialen.

Hotfix-grener

Hotfix-grener er også ment for å gi ut en ny versjon til hovedgrenen. Den eneste forskjellen er at disse utgivelsene ikke er planlagt. Det er situasjoner når feil kommer inn i den utgitte versjonen og oppdages i produksjonsmiljøet. Ta iOS: så snart en ny versjon er utgitt, får du umiddelbart en haug med oppdateringer med rettelser for feil som ble funnet etter utgivelsen. Følgelig må vi raskt fikse en feil og gi ut en ny versjon. På bildet vårt tilsvarer dette versjon 1.0.1. Tanken er at arbeidet med ny funksjonalitet ikke trenger å stoppe når det er nødvendig å fikse en feil på en ekte server (eller som vi sier "in prod" eller "in production"). Hurtigreparasjonsgrenen bør opprettes fra hovedgrenen, siden den representerer det som for øyeblikket kjører i produksjon. Så snart feilrettingen er klar, den slås sammen til master, og en ny tag opprettes. Akkurat som å forberede en utgivelsesgren, bør en hurtigreparasjonsgren også slå sammen reparasjonen tilbake til utviklingsgrenen.

Forking arbeidsflyt

I forking-arbeidsflyten involverer utvikling to depoter:

1. Det opprinnelige depotet, der alle endringer vil bli slått sammen.
2. Et gaffellager. Dette er en kopi av det originale depotet, eid av en annen utvikler som ønsker å gjøre endringer i originalen.

Høres litt rart ut så langt, ikke sant? Alle som allerede har vært borti åpen kildekode-utvikling er allerede kjent med denne tilnærmingen. Denne strategien gir følgende fordel: utvikling kan skje i et gaffellager uten å gi tillatelser til felles utvikling i den opprinnelige grenen. Eieren av det opprinnelige depotet har naturligvis rett til å avvise de foreslåtte endringene. Eller å godta og slå dem sammen. Dette er praktisk for både eieren av det opprinnelige depotet og utvikleren som ønsker å hjelpe til med å lage produktet. Du kan for eksempel foreslå endringer i Linux-kjernen . Hvis Linus bestemmer seg for at de er fornuftige, vil endringene bli lagt til (!!!).

Et eksempel på gaffelarbeidsflyten

Forking-arbeidsflyten brukes på GitHub når det er et bibliotek du vil bruke. Den har en feil som hindrer deg i å bruke den fullt ut. Anta at du dykker dypt nok inn i problemet og vet løsningen. Ved å bruke forking-arbeidsflyten kan du fikse problemet uten rettigheter til å jobbe i bibliotekets originale depot. For å komme i gang må du velge et eller annet depot, for eksempel Spring Framework . Finn og klikk på "Fork"-knappen i øvre høyre hjørne: Dette vil ta litt tid. Deretter vil en kopi av det originale depotet vises på din personlige konto, som vil indikere at det er en gaffel:Nå kan du jobbe med dette depotet som vanlig, legge til endringer i mastergrenen, og når alt er klart, kan du opprette en pull-forespørsel til det originale depotet. For å gjøre dette, klikk på Ny pull request- knappen:

Hvilken strategi å velge

Git er et fleksibelt og kraftig verktøy som lar deg jobbe ved å bruke en lang rekke prosesser og strategier. Men jo flere valg du har, jo vanskeligere er det å bestemme hvilken strategi du skal velge. Det er klart at det ikke finnes et enkelt svar for alle. Alt avhenger av situasjonen. Når det er sagt, er det flere retningslinjer som kan hjelpe med dette:

1. Det er best å velge den enkleste strategien først. Gå til mer komplekse strategier bare når det er nødvendig.
2. Vurder strategier som har så få grentyper som mulig for utviklere.
3. Se på fordeler og ulemper ved de ulike strategiene, og velg deretter den du trenger for prosjektet ditt.

Det var alt jeg ville si om forgreningsstrategier i Git. Takk for oppmerksomheten :) Følg meg på GitHub , hvor jeg ofte legger ut kreasjonene mine som involverer forskjellige teknologier og verktøy som jeg bruker i arbeidet mitt.