Detta dokument skrevs för att förenhetliga företagets interna GitFlow-regler. Denna metod är inte att införa ren GitFlow, eftersom det är en blandning av både GitFlow och GitLab Flow, med bästa företagspraxis som arbetats under många år. Det hjälper till att hålla en ren och läsbar historia av förvaret och bättre kontroll över ändringar och projekt livscykler.

Initialisering av förvaret

När du har initialiserat arkivet skapar du en utveckla och mästare om den inte ingår som standard. Utvecklingsgrenen bör innehålla en utvecklings kod som är en spegel av mastergrenen med nya funktioner inkluderade. Master innehåller en stabil version av koden som representerar produktionstillståndet. Båda har oändliga livstider och kommer, i jämförelse med andra grenar i Git Flow, aldrig att tas bort. Sätt upp lämpliga skyddsregler: kräver att dra begäran recensioner innan sammanslagning och kräver att statuskontroller godkänns innan sammanslagning. Du kan också överväga att endast tillåta utvalda Team medlemmar för att sammanfoga ändringar till master.

$ git init
$ git commit --allow-empty -m "Inledande commit"
$ git checkout -b utveckla master

OBS! Ibland är det viktigt för projektet att lägga till fler oändliga grenar, t.ex. för att representera tillgängliga miljöer. Håll dig dock till "tvåregeln" om det är möjligt.

Funktion grenar

När du börjar arbeta med en viss funktion ska du först se till att du har din utveckla filial synkroniserad.

 $ git checkout develop && git pull --rebase

Checka sedan ut till din feature branch. Namnge den enligt det angivna schemat: funktion-JIRA-TASK-ID eller så kan du också bryta mot den regeln och ge den ett annat namn. I så fall ska du se till att det inte står i konflikt med mönster som är reserverade för release, hotfix, bugfix, utveckling eller huvudgrenen. Att behålla JIRA-uppgifts-ID:n hjälper dig att hantera dina funktionsgrenar mer effektivt.

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

Den här grenen bör finnas så länge som den aktuella funktionen utvecklas och sedan sammanfogas till den överordnade grenen. Följ detta kommando för att ansluta till din lokala gren:

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

Det rekommenderas att du lägger till fler commits till din lokala gren, enligt regeln "Commit early and often". I slutändan måste de dock pressas ihop till en enda commit som representerar en JIRA Task. Att ofta göra commits hjälper dig att hantera din utvecklingshistorik. När funktionen är klar är det dags att öppna en Pull Request för att utveckla en gren. Först kan du pusha din lokala gren om den inte har pushats för långt:

 $ git push origin funktion-JIRA-TASK-ID

När grenen är klar öppnar du din dra begäran på GitHub genom att följa den här artikeln: https://help.github.com/en/articles/creating-a-pull-request

Innan du öppnar en pull-begäran ska du kontrollera följande:

• a korrekt beskrivning har getts - vanligtvis skulle du länka din JIRA-uppgiftmen du kan också inkludera användbar information som är relaterad till den aktuella koden
• CircleCI stegen passerades framgångsrikt
• din Teammedlemmarna tilldelades - det är god praxis att inkludera alla dina teammedlemmar som uppdragstagare
• den granskare valdes ut - antalet granskare beror på ditt team
• din kod faktiskt är klar för granskning - ta en sista titt på din kod, fundera en gång till om det finns något kvar att refaktorisera, testa den lokalt och se till att den är redo för ytterligare steg.
• det finns inga sammanfogningskonflikter och en gren är uppdaterad med develop - om det finns några, lösa dem först

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # använd -i flagga för squash
$ git push -f origin feature-JIRA-TASK-ID # Använd detta noggrant eftersom -f flaggan skriver över fjärrförvaret

• behåll endast viktiga åtaganden - varje commit bör representeras av en JIRA-uppgift, till exempel, JIRA-TASK-ID: Konfiguration av ny funktion; andra bör vara klämd vid ombasering din gren med develop-grenen
• du har rätt destination filial vald
• du glömmer inte att ändra status för din JIRA-uppgift

Sammanslagning av funktionsgren

Det är dags att slå samman dina ändringar till utvecklingsgrenen när:

• pull request godkändes av utvalda teammedlemmar
• alla tester avslutades framgångsrikt
• det finns inga sammanfogningskonflikter och commit-historiken ser bra ut

Detta kan göras av antingen projektledaren eller funktionsutvecklaren. Följ dessa steg för att utföra sammanslagningen:

 $ git utcheckning utveckla
 $ git sammanslagning av funktion-JIRA-TASK-ID
 $ git push ursprung utveckla
 $ git branch -d funktion-JIRA-TASK-ID
 $ git push origin :funktion-JIRA-TASK-ID

Nu kan statusen för JIRA-uppgifter ändras.

Utgåvor

Releasegrenar bör skapas av en person som är ansvarig för den aktuella releasen. Vanligtvis skapas releaser med jämna mellanrum, t.ex. enligt sprint livscykel.

Semantisk versionshantering

Att ge en releasegren ett korrekt namn och en motsvarande tagg är inte en lätt uppgift i början. Det är god praxis att börja använda semantisk versionshantering (https://semver.org/) vilket ger bättre kontroll och gör det enklare att läsa git-historiken. Versionssträngen är konstruerad enligt MAJOR.MINOR.PATCH-schemat:

• MAJOR - ändring som representerar inkompatibla API-ändringar
• MINOR - lägga till nya funktioner på ett bakåtkompatibelt sätt
• PATCH - lägger till bakåtkompatibla buggfixar

Du kan också använda speciella suffix, t.ex. sådana som representerar beta- eller legacy-grenar, eller skapa förhandsreleaser. I så fall ska du namnge den på rätt sätt, t.ex. 1.1.0-beta.4, 1.1.0-beta.5 eller 1.1.0-alpha.

Att göra en release

Releasegrenen bör vara underordnad utvecklingsgrenen och får endast innehålla åtaganden som rör buggfixar.

Grennamnet ska baseras på releaseversionen, med prefixet release-: release-MAJOR.MINOR.PATCH. Release-grenen bör vara fullt testad både automatiskt och manuellt på staging-miljö. Om buggar uppstår är detta sista chansen att skicka in rätt korrigeringar och köra hela processen igen, så länge den inte är positivt kontrollerad och redo för vidare bearbetning. Sedan ska release commit skjutas, med ändringar av den aktuella versionssträngen i filer, till exempel package.json. Det bör också ha en inverkan på filen CHANGELOG.md. Detta hjälper dig att spåra alla ändringar före en korrekt release och förbereda innehållet för GitHub-release när sammanslagningsprocessen är klar. Uppdateringen av den enskilda filen bör bestå av alla ändringar i releasen grupperade i tre kategorier: funktioner, korrigeringar och underhåll.

I det första steget ska du dock se till att du har både dina develop- och master-filialer uppdaterade.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git sammanslagning master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Produkt Namn M.M.P-utgåva"
 $ git push origin release-M.M.P

Vid den här tidpunkten kan man besluta sig för att skapa en ny pull request till master med release-grenen. Det kan vara en bra idé att köra en extra kontroll om alla tester går bra på fjärrmaskinen.

 $ git checkout master
 $ git sammanslagning release-M.M.P
 $ git tag -a M.M.P # tilläggsmeddelande kan ställas in via -m flagga
 $ git push origin M.M.P
 $ git push ursprung master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Gå sedan till sidan GitHub-utgåvor och tryck på knappen "Draft new release". I det visade formuläret väljer du taggen för aktuell version, ställer in releasetiteln som liknar release commit (Product Name M.M.P release) och en korrekt beskrivning, baserat på filen CHANGELOG.md. För offentliga projekt bör beskrivningen innehålla en lista över alla PR som ingår i den aktuella utgåvan.

Om vissa buggfixar tillämpades på release-grenen ska du se till att din develop-gren är uppdaterad:

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

Uppdateringar och buggfixar

Den största skillnaden mellan en bugg och en snabbkorrigering är deras målgrenar.

Buggfix

Buggfixar bör patcha release-grenar som den enda formen av uppdatering av kod innan den sammanfogas till master. Skapa först grenen från den aktuella funktionsgrenen. Se till att du har den uppdaterad lokalt.

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

Gör sedan de nödvändiga ändringarna. När processen är klar skapar du en pull request och riktar den till release-grenen. Följ vägledningen i avsnittet om funktionsgrenar. Din slutliga commit-titel ska matcha det givna schemat: "Bugfix M.M.P: Problem essence fix". När pull request är godkänd är det dags att sammanfoga den till den aktuella releasen.

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

Snabbkorrigering

För att utföra en hotfix på huvudgrenen måste mycket liknande steg som för en bugfix vidtas, med tanke på att målgrenen nu är huvudgrenen.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representerar aktuell version

Följ sedan de vanliga utvecklingsstegen och när processen är klar skapar du en pull request med mastergrenen som mål. Tänk på att den sista commit ska matcha det givna schemat "Hotfix X.Y.(Z + 1): Problem essence fix". När varje kontrollpunkt har passerat framgångsrikt, utför en sammanslagning till master. Dessa steg skiljer sig från det som presenteras för en buggfix, eftersom vi måste höja den aktuella releaseversionen.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # tilläggsmeddelande kan ställas in via -m flagga
 $ git push origin X.Y.(Z+1)
 $ git push ursprung 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

Fuskark

Init förvaringsplats

 $ git init
 $ git commit --allow-empty -m "Initial commit"
 $ git checkout -b utveckla master
 $ git push ursprung utveckla
 $ git push ursprung master

Funktioner

$ git checkout develop && git pull --rebase
$ git utcheckning -b funktion-JIRA-TASK-ID utveckla

Starta din utveckling och dina åtaganden

$ git add .
$ git commit -m "IRA-TASK-ID: Uppgiftsbeskrivning" #initial commit
$ git push ursprung funktion-JIRA-TASK-ID

Öppna pull request

Ombasera och förbered för pull request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # använd -i flaggan för squash
$ git push -f origin feature-JIRA-TASK-ID # Använd detta noggrant eftersom -f flaggan skriver över fjärrförvaret

Sammanfoga ändringar och ta bort filial

$ git checkout develop #-grenen bör synkroniseras med utvecklingsgrenen i detta skede
$ git sammanfoga funktion-JIRA-TASK-ID
$ git push origin develop
$ git branch -d funktion-JIRA-TASK-ID
$ git push origin :funktion-JIRA-TASK-ID

Utgåvor

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

Skapa release commit

$ git add .
$ git commit -m "Produktnamn M.M.P release" #initial commit
$ git push ursprung release-M.M.P

Öppna pull request

Sammanfoga ändringar, publicera och ta bort gren

$ git checkout master # gren bör synkroniseras med master gren i detta skede
$ git merge release-M.M.P
$ git tag -a M.M.P # tilläggsmeddelande kan ställas in via -m flagga
$ git push origin M.M.P
$ git push ursprung master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Buggfix

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

$ Bekräfta korrigeringar
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Öppna pull request

Sammanfoga ändringar och ta bort filial

$ git checkout release-M.M.P #-grenen bör synkroniseras med den aktuella release-grenen i detta skede
$ 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

Snabbkorrigering

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representerar aktuell version

$ Bekräfta korrigeringar
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Öppna pull request

Slå samman ändringar, släpp och ta bort branc

$ git checkout master # gren bör synkroniseras med nuvarande master i detta skede
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # tilläggsmeddelande kan ställas in via -m flagga
$ git push origin X.Y.(Z+1)
$ git push ursprung 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

Läs mer om detta:

• Codest's goda praxis för att bygga programvara: CircleCI
• Hur skapar jag Google Chrome-tillägg med hjälp av Netflix undertextstyler?
• React: det mest populära ramverket JavaScript