Dette dokumentet ble skrevet for å forene de interne GitFlow-reglene i selskapet. Denne metoden introduserer ikke ren GitFlow, da den er en blanding av både GitFlow og GitLab Flow, med beste praksis i selskapet som er utarbeidet over mange år. Det bidrar til å holde en ren og lesbar historikk over depotet og bedre kontroll over endringer og prosjekt livssyklus.

Initialisering av repositoriet

Etter at du har initialisert depotet, oppretter du en utvikle og mester grenen hvis den ikke var inkludert som standard. Utviklingsgrenen bør inneholde en utviklings kode som er et speilbilde av master-grenen med nye funksjoner inkludert. Mastergrenen inneholder en stabil versjon av koden, som representerer produksjonstilstanden. Begge har uendelig levetid, og i motsetning til andre grener i Git Flow vil de aldri bli fjernet. Sett opp riktige beskyttelsesregler: krever gjennomgang av pull-forespørsler før sammenslåing og krever at statussjekker må bestås før sammenslåing. Du kan også vurdere å kun tillate utvalgte team medlemmer til å slå sammen endringer til masteren.

$ git init
$ git commit --allow-empty -m "Innledende commit"
$ git checkout -b develop master

MERK: Noen ganger er det viktig for prosjektet å legge til flere uendelige grener, for eksempel for å representere tilgjengelige miljøer. Men hold deg til "regelen om to" hvis det er mulig.

Funksjonsgrener

Når du begynner å jobbe med en gitt funksjon, må du først forsikre deg om at du har utvikle gren synkronisert.

 $ git checkout develop && git pull --rebase

Sjekk deretter ut til funksjonsgrenen din. Gi den et navn i henhold til det gitte skjemaet: funksjon-JIRA-TASK-ID eller du kan også bryte denne regelen og gi den et annet navn. I så fall må du sørge for at den ikke kommer i konflikt med mønstre som er reservert for release, hotfix, bugfix, utvikling eller master-grenen. Ved å beholde JIRA-oppgave-ID-er kan du administrere funksjonsgrenene dine mer effektivt.

$ git checkout -b feature-JIRA-TASK-ID develop

Denne grenen bør eksistere så lenge den aktuelle funksjonen utvikles og deretter slås sammen med den overordnede grenen. Følg denne kommandoen for å forplikte deg til din lokale gren:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Oppgavebeskrivelse"

Det anbefales at du legger til flere commits i den lokale grenen, og følger regelen "Commit early and often". Til slutt må de imidlertid samles i én enkelt commit som representerer en JIRA-oppgave. Ved å committe ofte får du bedre oversikt over utviklingshistorikken din. Når funksjonen er klar, er det på tide å åpne en Pull Request for å utvikle en gren. Først kan du pushe den lokale grenen hvis den ikke har blitt pushet for langt:

 $ git push origin feature-JIRA-TASK-ID

Når grenen er klar, åpner du pull-forespørsel på GitHub, ved å følge denne artikkelen: https://help.github.com/en/articles/creating-a-pull-request

Før du åpner en pull-forespørsel, må du forsikre deg om følgende:

• a riktig beskrivelse har blitt gitt - vanligvis vil du koble JIRA-oppgaven dinmen du kan også inkludere nyttig informasjon knyttet til den aktuelle koden
• CircleCI trinnene ble bestått med suksess
• din teammedlemmer ble tildelt - det er god praksis å inkludere alle teammedlemmene dine som oppdragstakere
• den anmeldere ble valgt ut - Antall korrekturlesere avhenger av teamet ditt
• koden din faktisk er klar for gjennomgang - ta en siste titt på koden din, tenk en gang til om det er noe igjen å refaktorere, test den lokalt og sørge for at den er klar for videre trinn.
• det finnes ingen flettekonflikter og en gren er oppdatert med develop - hvis det er noen, må du løse dem først

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # bruk -i flagget for squash
$ git push -f origin feature-JIRA-TASK-ID # Bruk dette forsiktig, da -f-flagget overskriver det eksterne depotet

• bare beholde viktige forpliktelser - hver forpliktelse skal representeres av en JIRA-oppgave, for eksempel, JIRA-TASK-ID: Konfigurasjon av ny funksjon; andre bør være knust under ombasering grenen din med utviklingsgrenen
• du har riktig destinasjonsgren valgt
• du ikke glemmer å endre statusen til JIRA-oppgaven din

Sammenslåing av funksjonsgren

Det er på tide å slå sammen endringene dine til utviklingsgrenen når:

• pull-forespørselen ble godkjent av utvalgte teammedlemmer
• alle tester fullført med suksess
• det er ingen sammenslåingskonflikter, og commit-historikken ser fin ut

Dette kan gjøres av enten prosjektlederen eller funksjonsutvikleren. Følg disse trinnene for å utføre sammenslåingen:

 $ git checkout develop
 $ git merge feature-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d funksjon-JIRA-TASK-ID
 $ git push origin :funksjon-JIRA-TASK-ID

Nå kan JIRA-oppgavestatus endres.

Utgivelser

Release-grener bør opprettes av en person som er ansvarlig for den aktuelle releasen. Vanligvis opprettes utgivelser med jevne mellomrom, for eksempel i henhold til sprint livssyklus.

Semantisk versjonering

Å gi en releasegren et riktig navn og en tilhørende tagg er ikke en enkel oppgave helt i begynnelsen. Det er god praksis å begynne å bruke semantisk versjonering (https://semver.org/), noe som gir bedre kontroll og gjør det enklere å lese git-historikken. Versjonsstrengen er konstruert i henhold til MAJOR.MINOR.PATCH-skjemaet:

• MAJOR - endring som representerer inkompatible API-endringer
• MINOR - legger til nye funksjoner på en bakoverkompatibel måte
• PATCH - legger til bakoverkompatible feilrettinger

Du kan også bruke spesielle suffikser, for eksempel de som representerer beta- eller legacy-grener, eller opprette forhåndsutgivelser. I så fall må du gi den et passende navn, f.eks. 1.1.0-beta.4, 1.1.0-beta.5 eller 1.1.0-alpha.

Lage en utgivelse

Release-grenen skal være underordnet develop og kan bare inneholde kommitteringer knyttet til feilrettinger.

Grennavnet skal være basert på utgivelsesversjonen, med prefikset release-: release-MAJOR.MINOR.PATCH. Release-grenen bør være fullt testet både automatisk og manuelt på iscenesettelsesmiljø. Hvis det oppstår feil, er dette siste mulighet til å pushe riktige rettelser og kjøre hele prosessen på nytt, så lenge den ikke blir positivt kontrollert og klar for videre behandling. Deretter bør release commit skyves, med endringer av den gjeldende versjonsstrengen i filer, for eksempel package.json. Det bør også ha en innvirkning på CHANGELOG.md-filen. Dette vil hjelpe deg med å spore alle endringer før en riktig utgivelse og forberede innholdet for GitHub-utgivelse når sammenslåingsprosessen er fullført. Oppdateringen av én fil bør bestå av alle endringer i utgivelsen, gruppert i tre kategorier: funksjoner, rettelser og vedlikehold.

I det første trinnet må du imidlertid sørge for at både develop- og master-grenene dine er oppdaterte.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Produkt Navn M.M.P-utgivelse"
 $ git push origin release-M.M.P

På dette tidspunktet kan man bestemme seg for å opprette en ny pull-forespørsel til masteren med release-grenen. Det kan være en god idé å kjøre en ekstra sjekk for å se om alle testene går bra på den eksterne maskinen.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # tilleggsmelding kan settes via -m flagget
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Gå deretter til GitHub-utgivelsessiden og trykk på knappen "Draft new release". I skjemaet som vises, velger du taggen for gjeldende versjon, angir utgivelsestittelen som ligner på utgivelsesforpliktelsen (produktnavn M.M.P-utgivelse) og en riktig beskrivelse, basert på CHANGELOG.md-filen. For offentlige prosjekter bør beskrivelsen inneholde en liste over alle PR-er som er inkludert i den gjeldende versjonen.

Hvis noen feilrettinger ble brukt på utgivelsesgrenen, må du sørge for at utviklingsgrenen din er oppdatert:

$ git checkout develop && git merge master
$ git push origin develo

Oppdateringer og feilrettinger

Hovedforskjellen mellom en feilretting og en hotfix er målgrenene.

Feilretting

Feilrettinger bør patche release-grener som den eneste formen for oppdatering av kode før den slås sammen til master. Først oppretter du grenen fra den nåværende funksjonsgrenen. Sørg for at du har den oppdatert lokalt.

<$ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Gjør deretter de nødvendige endringene. Når prosessen er ferdig, oppretter du en pull-forespørsel og sender den til utgivelsesgrenen. Følg veiledningen fra delen om funksjonsgrenen. Den endelige commit-tittelen bør samsvare med det gitte skjemaet: "Bugfix M.M.P: Problem essence fix". Når pull-forespørselen er godkjent, er det på tide å slå den sammen med den gjeldende utgivelsen.

 $ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Hotfix

For å utføre en hurtigreparasjon på mastergrenen må man gå frem på samme måte som ved en feilretting, men husk at målgrenen nå er mastergrenen.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representerer gjeldende versjon

Deretter følger du de vanlige utviklingstrinnene, og når prosessen er ferdig, oppretter du en pull-forespørsel med master-grenen som mål. Husk at den endelige forpliktelsen skal samsvare med det gitte skjemaet "Hotfix X.Y.(Z + 1): Problem essence fix". Når alle sjekkpunktene har passert, kan du utføre en sammenslåing til master. Disse trinnene skiller seg fra det som presenteres for en feilretting, ettersom vi må flytte den gjeldende utgivelsesversjonen.

<$ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # tilleggsmelding kan settes via -m flagget
 $ git push origin X.Y.(Z+1)
 $ git push origin master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin develop

Jukseark

Init depot

 $ git init
 $ git commit --allow-empty -m "Innledende forpliktelse"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Funksjoner

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Start utviklingen og forpliktelsene dine

$ git add .
$ git commit -m "IRA-TASK-ID: Oppgavebeskrivelse" #initial commit
$ git push origin funksjon-JIRA-TASK-ID

Åpne pull-forespørsel

Rebase og klargjøre for pull-forespørsel

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # bruk -i flagget for squash
$ git push -f origin feature-JIRA-TASK-ID # Bruk dette forsiktig, da -f-flagget overskriver det eksterne depotet

Slå sammen endringer og slett gren

$ git checkout develop #-grenen bør synkroniseres med develop-grenen på dette stadiet
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d funksjon-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Utgivelser

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Opprett release commit

$ git add .
$ git commit -m "Produktnavn M.M.P-utgivelse" #initial commit
$ git push origin release-M.M.P

Åpne pull-forespørsel

Slå sammen endringer, publiser og slett gren

$ git checkout master #-grenen bør synkroniseres med master-grenen på dette stadiet
$ git merge release-M.M.P
$ git tag -a M.M.P # tilleggsmelding kan angis via -m-flagget
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Feilretting

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Kommitter rettelser
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Åpne pull-forespørsel

Slå sammen endringer og slett gren

$ git checkout release-M.M.P #-grenen bør synkroniseres med den nåværende utgivelsesgrenen på dette stadiet
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P

Hotfix

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representerer gjeldende versjon

$ Kommitter rettelser
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Åpne pull-forespørsel

Slå sammen endringer, publiser og slett filialer

$ git checkout master #-grenen skal synkroniseres med nåværende master på dette stadiet
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # tilleggsmelding kan angis via -m-flagget
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop

Les mer om dette:

• Codests gode praksis for å bygge programvare: CircleCI
• Hvordan lage Google Chrome-utvidelser ved hjelp av Netflix-undertekststyleren?
• React: det mest populære JavaScript-rammeverket