Dette dokument blev skrevet for at ensrette virksomhedens interne GitFlow-regler. Denne metode introducerer ikke ren GitFlow, da det er en blanding af både GitFlow og GitLab Flow med bedste virksomhedspraksis, der er arbejdet med gennem mange år. Det hjælper med at holde en ren og læsbar historik over repository'et og bedre kontrol over ændringer og projekt livscyklusser.

Initialisering af depot

Når du har initialiseret depotet, skal du oprette en udvikle sig og mester gren, hvis den ikke var inkluderet som standard. Udviklingsgrenen bør indeholde en udviklings Kode der er et spejl af master-grenen med nye funktioner inkluderet. Master indeholder en stabil version af koden, som repræsenterer produktionstilstanden. Begge har uendelig levetid, og i sammenligning med andre grene i Git Flow vil de aldrig blive fjernet. Opsæt ordentlige beskyttelsesregler: kræver at pull request-anmeldelser før sammenlægning og kræver, at statustjek skal bestå før fletning. Du kan også overveje kun at tillade udvalgte hold medlemmer til at flette ændringer til master.

$ git init
$ git commit --allow-empty -m "Første commit"
$ git checkout -b develop master

BEMÆRK: Nogle gange er det vigtigt for projektet at tilføje flere uendelige grene, f.eks. for at repræsentere tilgængelige miljøer. Men hold fast i "reglen om to", hvis det er muligt.

Funktionelle grene

Når du begynder at arbejde med en given funktion, skal du først sikre dig, at du har din udvikle sig gren synkroniseret.

 $ git checkout develop && git pull --rebase

Tjek derefter ud til din feature-gren. Navngiv den i henhold til det givne skema: funktion-JIRA-TASK-ID eller du kan også bryde den regel og navngive den anderledes. I så fald skal du sørge for, at den ikke er i konflikt med mønstre, der er reserveret til release, hotfix, bugfix, udvikling eller master-grenen. Ved at beholde JIRA-opgave-ID'er kan du administrere dine feature branches mere effektivt.

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

Denne gren bør eksistere, så længe den givne funktion udvikles og derefter flettes til den overordnede gren. Følg denne kommando for at committe til din lokale gren:

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

Det anbefales, at du tilføjer flere commits til din lokale gren og følger reglen "Commit early and often". I sidste ende skal de dog samles i en enkelt commit, som repræsenterer en JIRA-opgave. At committe ofte hjælper dig med at styre din udviklingshistorik. Når funktionen er klar, er det tid til at åbne en Pull Request for at udvikle en branch. Først kan du skubbe din lokale gren, hvis den ikke er skubbet for langt:

 $ git push origin feature-JIRA-TASK-ID

Når grenen er klar, skal du åbne din pull-anmodning på GitHub ved at følge denne artikel: https://help.github.com/en/articles/creating-a-pull-request

Før du åbner en pull request, skal du sikre dig følgende:

• a korrekt beskrivelse er blevet givet - normalt ville du Link din JIRA-opgavemen du kan også inkludere nogle nyttige oplysninger relateret til den aktuelle kode
• CircleCI trin blev bestået med succes
• din Teammedlemmer blev tildelt - Det er god praksis at inkludere alle dine teammedlemmer som modtagere.
• den Anmeldere blev udvalgt - Antallet af korrekturlæsere afhænger af dit team
• din kode faktisk er klar til gennemgang - tag et sidste kig på din kode, tænk igen, hvis der er noget tilbage at refaktorere, test det lokalt og sikre, at den er klar til yderligere trin.
• der er ingen flettekonflikter, og en gren er opdateret med develop - Hvis der er nogen, så løs dem først

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # brug -i flag til squash
$ git push -f origin feature-JIRA-TASK-ID # Brug dette omhyggeligt, da -f-flaget overskriver remote repository

• Behold kun vigtige commits - Hver commit skal repræsenteres af en JIRA-opgave, for eksempel, JIRA-TASK-ID: Konfiguration af ny funktion; andre bør være knust under ombasering din gren med develop-grenen
• du har den korrekt destinationsgren valgt
• du ikke glemmer at ændre status for din JIRA-opgave

Sammenlægning af funktionsgren

Det er tid til at flette dine ændringer til udviklingsgrenen, når:

• pull-anmodningen blev godkendt af udvalgte teammedlemmer
• alle tests er afsluttet med succes
• der er ingen flettekonflikter, og commit-historikken ser fin ud

Dette kan gøres af enten projektlederen eller funktionsudvikleren. Følg disse trin for at udføre sammenlægningen:

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

Nu kan JIRA-opgavens status ændres.

Udgivelser

Udgivelsesgrene bør oprettes af en person, der er ansvarlig for den aktuelle udgivelse. Normalt oprettes udgivelser med jævne mellemrum, for eksempel i henhold til sprint livscyklus.

Semantisk versionering

At give en udgivelsesgren et ordentligt navn og et tilsvarende tag er ikke en let opgave i begyndelsen. Det er god praksis at begynde at bruge semantisk versionering (https://semver.org/), hvilket giver bedre kontrol og gør det lettere at læse git-historien. Versionsstrengen er konstrueret i henhold til MAJOR.MINOR.PATCH-skemaet:

• MAJOR - ændring, der repræsenterer inkompatible API-ændringer
• MINOR - tilføjer nye funktioner på en bagudkompatibel måde
• PATCH - tilføjer bagudkompatible fejlrettelser

Du kan også bruge særlige suffikser, f.eks. dem, der repræsenterer beta- eller legacy-grene, eller oprette pre-releases. I så fald skal du navngive den korrekt, f.eks. 1.1.0-beta.4, 1.1.0-beta.5 eller 1.1.0-alpha.

At lave en udgivelse

Release-grenen skal være underordnet develop og kan kun indeholde commits, der er forbundet med fejlrettelser.

Grennavnet skal være baseret på udgivelsesversionen med præfikset release-: release-MAJOR.MINOR.PATCH. Release-grenen bør være fuldt testet både automatisk og manuelt på scenemiljø. Hvis der opstår fejl, er dette den sidste mulighed for at skubbe korrekte rettelser og køre hele processen igen, så længe den ikke er positivt kontrolleret og klar til videre behandling. Derefter skal release-commit'en skubbes med ændringer af den aktuelle versionsstreng i filer som package.json. Det bør også have indflydelse på filen CHANGELOG.md. Dette vil hjælpe dig med at spore alle ændringer før en egentlig udgivelse og forberede indholdet til GitHub-udgivelse, når fletteprocessen er afsluttet. Den enkelte filopdatering bør bestå af alle ændringer til udgivelsen grupperet i tre kategorier: funktioner, rettelser og vedligeholdelse.

I det første trin skal du dog sørge for, at både din develop- og master-gren er opdateret.

 $ 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-udgivelse"
 $ git push origin release-M.M.P

På dette tidspunkt kan man beslutte at oprette en ny pull request til master med release-grenen. Det kan være en god idé at køre en ekstra kontrol af, om alle test går godt på fjernmaskinen.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # tilføjelsesmeddelelse kan indstilles via -m flag
 $ 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å derefter til GitHubs udgivelsesside, og tryk på knappen "Udarbejd ny udgivelse". I den viste formular skal du vælge tagget for den aktuelle version, indstille udgivelsestitlen svarende til udgivelsescommit'et (Product Name M.M.P release) og en passende beskrivelse baseret på filen CHANGELOG.md. For offentlige projekter skal beskrivelsen indeholde en liste over alle PR'er, der er inkluderet i den aktuelle udgivelse.

Hvis nogle fejlrettelser blev anvendt på udgivelsesgrenen, skal du sikre dig, at din udviklingsgren er opdateret:

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

Hotfixes og fejlrettelser

Den største forskel mellem en bug og hot fixes er deres målgrene.

Bugfix

Fejlrettelser bør patche udgivelsesgrene som den eneste form for opdatering af kode, før den flettes til master. Opret først grenen fra den nuværende feature-gren. Sørg for, at du har den opdateret lokalt.

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

Commit derefter de nødvendige ændringer. Når processen er færdig, skal du oprette en pull request og sende den til release-grenen. Følg vejledningen fra afsnittet om funktionsgrenen. Din endelige commit-titel skal matche det givne skema: "Bugfix M.M.P: Problem essence fix". Når pull request'en er godkendt, er det tid til at flette den ind i den aktuelle udgivelse.

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

Hotfix

For at udføre en hotfix på master-grenen skal der tages meget lignende skridt som ved en bugfix, men man skal huske på, at målgrenen nu er master-grenen.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P repræsenterer den aktuelle udgivelse

Følg derefter de sædvanlige udviklingstrin, og når processen er færdig, skal du oprette en pull request med master-grenen som mål. Husk, at den endelige commit skal matche det givne skema "Hotfix X.Y.(Z + 1): Problem essence fix". Når alle kontrolpunkter er bestået, skal du flette til master. Disse trin adskiller sig fra det, der præsenteres for et bugfix, da vi er nødt til at flytte den aktuelle udgivelsesversion.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # tilføjelsesmeddelelse kan indstilles via -m flag
 $ 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

Snydeark

Start opbevaringssted

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

Funktioner

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

Start din udvikling og dine commits

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

Åbn pull request

Rebase og forbered pull request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # brug -i flag til squash
$ git push -f origin feature-JIRA-TASK-ID # Brug dette omhyggeligt, da -f-flaget overskriver remote repository

Flet ændringer og slet gren

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

Udgivelser

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

Opret release-commit

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

Åbn pull request

Flet ændringer, udgiv og slet gren

$ git checkout master #-grenen bør synkroniseres med master-grenen på dette tidspunkt
$ git merge udgivelse-M.M.P
$ git tag -a M.M.P # tilføjelsesmeddelelse kan indstilles via -m flag
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Bugfix

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

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

Åbn pull request

Flet ændringer og slet gren

$ git checkout release-M.M.P #-grenen bør synkroniseres med den aktuelle udgivelsesgren på dette tidspunkt
$ 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 repræsenterer den aktuelle udgivelse

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

Åbn pull request

Flet ændringer, udgiv og slet branc

$ git checkout master #-grenen bør synkroniseres med den nuværende master på dette tidspunkt
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # tilføjelsesmeddelelse kan indstilles via -m flag
$ 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

Læs mere om det:

• Codest's gode praksis for at bygge software: CircleCI
• Hvordan opretter man Google Chrome-udvidelser ved hjælp af Netflix' undertekststyler?
• React: den mest populære JavaScript-ramme