Dit document is geschreven om de interne bedrijfsregels van GitFlow te harmoniseren. Deze methode introduceert geen pure GitFlow, omdat het een mix is van zowel GitFlow als GitLab Flow, met de beste bedrijfspraktijken die gedurende vele jaren zijn ontwikkeld. Het helpt om een schone en leesbare geschiedenis van het repository te houden en een betere controle over wijzigingen en project levenscycli.

Archief initialiseren

Maak na het initialiseren van het archief een ontwikkelen en master tak als deze er standaard niet in zit. De develop tak moet een development code dat een mirror is van de master branch met nieuwe mogelijkheden. De master bevat een stabiele versie van de code, die de productiestatus vertegenwoordigt. Beide hebben een oneindige levensduur, en in vergelijking met andere branches in Git Flow, zullen ze nooit verwijderd worden. Stel de juiste beschermingsregels in: pull-reviews vereisen voordat ze worden samengevoegd en vereisen dat statuscontroles slagen voordat er wordt samengevoegd. Je kunt ook overwegen om alleen gekozen team leden om wijzigingen samen te voegen naar de master.

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

OPMERKING: Soms is het belangrijk voor het project om meer oneindige takken toe te voegen, bijvoorbeeld om beschikbare omgevingen te representeren. Houd echter de "regel van twee" aan als dat mogelijk is.

Feature takken

Als je aan de slag gaat met een bepaalde functie, zorg er dan eerst voor dat je je ontwikkelen tak gesynchroniseerd.

 $ git checkout develop && git pull --rebase

Check dan uit naar je feature branch. Geef het respectievelijk de naam van het gegeven schema: kenmerk-JIRA-TASK-ID of je kunt die regel ook breken en het een andere naam geven. Zorg er in dit geval voor dat het niet conflicteert met patronen die gereserveerd zijn voor release, hotfix, bugfix, ontwikkeling of de master branch. Het bijhouden van JIRA taak-ID's zal je helpen om je feature branches effectiever te beheren.

$ git checkout -b functie-JIRA-TASK-ID ontwikkelen

Deze branch zou moeten bestaan zolang de gegeven functionaliteit ontwikkeld is en dan samengevoegd naar de bovenliggende branch. Om vast te leggen op je lokale branch, volg je dit commando:

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

Het wordt aanbevolen dat je meer commits toevoegt aan je lokale branch, volgens de "Commit vroeg en vaak" regel. Maar uiteindelijk moeten ze samengeperst worden in een enkele commit die een JIRA taak voorstelt. Vaak committen zal je helpen om je ontwikkelgeschiedenis te beheren. Als de functie klaar is, is het tijd om een Pull Request te openen om een branch te ontwikkelen. Eerst kun je je lokale branch pushen als die nog niet te ver gepushed is:

 $ git push origin functie-JIRA-TASK-ID

Als de tak klaar is, open dan je pull-verzoek op GitHub, door dit artikel te volgen: https://help.github.com/en/articles/creating-a-pull-request

Zorg voor het volgende voordat je een pull request opent:

• a goede beschrijving is gegeven - meestal zou je je JIRA-taak koppelenmaar je kunt ook wat nuttige informatie met betrekking tot de huidige code toevoegen
• CircleCI stappen zijn succesvol doorlopen
• je teamleden werden toegewezen - het is een goed gebruik om al je teamleden als gevolmachtigden op te nemen.
• de beoordelaars werden geselecteerd - het aantal beoordelaars hangt af van je team
• je code is eigenlijk klaar voor herziening - bekijk je code voor de laatste keer, denk nog eens na of er nog iets te refactoren valt, test het lokaal en zorg ervoor dat het klaar is voor verdere stappen.
• er geen samenvoegconflicten en een tak is up-to-date met develop - als die er zijn, los ze dan eerst op

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # gebruik -i vlag voor squash
$ git push -f origin feature-JIRA-TASK-ID #gebruik dit voorzichtig want -f vlag overschrijft remote repository

• bewaar alleen belangrijke commits - Elke vastlegging moet bijvoorbeeld vertegenwoordigd worden door een JIRA taak, JIRA-TASK-ID: Nieuwe functieconfiguratie; anderen moeten geplet tijdens het rebasen jouw tak met de develop tak
• heb je de juiste bestemmingstak geselecteerd
• vergeet je niet om de status van je JIRA taak wijzigen

Functietak samenvoegen

Het is tijd om je wijzigingen samen te voegen naar de ontwikkeltak wanneer:

• het pull verzoek is goedgekeurd door geselecteerde teamleden
• alle tests succesvol afgerond
• er zijn geen samenvoeg conflicten en de commit geschiedenis ziet er goed uit

Dit kan gedaan worden door de projectmanager of functieontwikkelaar. Volg deze stappen om de samenvoeging uit te voeren:

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

Nu kan de status van JIRA-taken worden gewijzigd.

Vrijgaven

Vrijgave takken moeten worden aangemaakt door een persoon die verantwoordelijk is voor de huidige release. Gewoonlijk worden releases periodiek aangemaakt, bijvoorbeeld volgens de sprint levenscyclus.

Semantisch versiebeheer

Het geven van een juiste naam en bijbehorende tag aan een release branch is niet eenvoudig in het prille begin. Het is een goede gewoonte om te beginnen met semantisch versiebeheer (https://semver.org/) die betere controle toestaat en het lezen van de git geschiedenis makkelijker maakt. De versie string wordt opgebouwd volgens het MAJOR.MINOR.PATCH schema:

• MAJOR - verandering die incompatibele API-wijzigingen vertegenwoordigt
• MINOR - nieuwe functies toevoegen op een achterwaarts compatibele manier
• PATCH - achterwaarts compatibele bugfixes toevoegen

Je kunt ook speciale achtervoegsels gebruiken, zoals die voor beta of legacy branches, of pre-releases maken. Geef het in dat geval de juiste naam, bijvoorbeeld 1.1.0-beta.4, 1.1.0-beta.5 of 1.1.0-alpha.

Een release maken

De release branch zou een kind van develop moeten zijn en zou alleen commits kunnen bevatten die verbonden zijn met bugfixes.

De branchnaam moet gebaseerd zijn op de releaseversie, met het release-voorvoegsel: release-MAJOR.MINOR.PATCH. De releasetak moet zowel automatisch als handmatig volledig getest op de staging-omgeving. Als er bugs optreden, is dit de laatste kans om de juiste fixes te pushen en het hele proces opnieuw uit te voeren, zolang het niet positief gecontroleerd is en klaar voor verdere verwerking. Dan moet de release commit gepushed worden, met wijzigingen van de huidige release versie string in bestanden, zoals package.json. Het zou ook een impact moeten hebben op het CHANGELOG.md bestand. Dit zal je helpen om alle wijzigingen voor een juiste release bij te houden en de inhoud voor te bereiden voor GitHub vrijgave als het samenvoegproces voltooid is. De update van het enkele bestand zou moeten bestaan uit alle release wijzigingen gegroepeerd in drie categorieën: features, fixes en onderhoud.

In de eerste stap moet je er echter voor zorgen dat zowel je develop als je master branches up-to-date zijn.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git samenvoegen master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Product Naam M.M.P release".
 $ git push origin release-M.M.P

Op dit punt kan men besluiten om nog een pull request aan te maken naar de master met de release branch. Het kan een goed idee zijn om een extra controle uit te voeren als alle tests goed slagen op de machine op afstand.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # toevoeging bericht kan ingesteld worden via -m vlag
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push oorsprong :release-M.M.P

Ga dan naar de GitHub releases pagina en druk op de "Draft new release" knop. In het getoonde formulier, selecteer de huidige versie tag, stel de release titel gelijk aan de release commit (Product Name M.M.P release) en een goede beschrijving in, gebaseerd op het CHANGELOG.md bestand. Voor openbare projecten moet de beschrijving een lijst bevatten van alle PR's die in de huidige release zijn opgenomen.

In het geval dat sommige bugfixes zijn toegepast op de release branch, zorg er dan voor dat je develop branch is bijgewerkt:

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

Hotfixes en bugfixes

Het belangrijkste verschil tussen een bug en hot fixes is hun doeltakken.

Bugfix

Bugfixes zouden release branches moeten patchen als de enige vorm van het bijwerken van code voordat het samengevoegd wordt naar master. Maak eerst de branch van de huidige feature branch. Zorg ervoor dat je het lokaal up-to-date hebt.

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

commit dan de benodigde wijzigingen. Nadat het proces klaar is, maak je een pull request aan en target je het naar de release branch. Volg de richtlijnen van de feature branch sectie. Je uiteindelijke commit titel moet overeenkomen met het gegeven schema: "Bugfix M.M.P: Probleem essentie fix". Als het pull verzoek is goedgekeurd, is het tijd om het samen te voegen naar de huidige release.

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

Hotfix

Om een hotfix op de master branch uit te voeren, moeten zeer vergelijkbare stappen als bij een bugfix genomen worden, in gedachten houdend dat de doelbranch nu de master branch is.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P staat voor huidige release

Volg dan de gebruikelijke ontwikkelstappen en als het proces klaar is, maak dan een pull request aan met de master branch als doel. Houd in gedachten dat de laatste commit overeen moet komen met het gegeven schema "Hotfix X.Y.(Z + 1): Probleem essentie fix". Als elk controlepunt succesvol is gepasseerd, voer dan een samenvoeging naar master uit. Deze stappen verschillen van degene die gepresenteerd worden voor een bugfix, omdat we de huidige release versie moeten bulken.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # toevoeging bericht kan ingesteld worden via -m vlag
 $ git push origin X.Y.(Z+1)
 $ git push oorsprong 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

Spiekbriefje

Init archief

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

Kenmerken

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

Begin je ontwikkeling en commits

$ git add .
$ git commit -m "IRA-TASK-ID: Taak omschrijving" #initial commit
$ git push origin kenmerk-JIRA-TASK-ID

Open pull-verzoek

Rebasen en voorbereiden voor pull-aanvraag

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # gebruik -i vlag voor squash
$ git push -f origin feature-JIRA-TASK-ID # gebruik dit voorzichtig want -f vlag overschrijft remote repository

Wijzigingen samenvoegen en tak verwijderen

$ git checkout develop # branch moet in dit stadium gesynchroniseerd zijn met develop branch
$ git samenvoegen kenmerk-JIRA-TASK-ID
$ git push origin develop
$ git branch -d kenmerk-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Vrijgaven

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

Maak release commit aan

$ git add .
$ git commit -m "Productnaam M.M.P release" #initial commit
$ git push oorsprong release-M.M.P

Open pull-verzoek

Wijzigingen samenvoegen, tak vrijgeven en verwijderen

$ git checkout master # branch zou in dit stadium gesynchroniseerd moeten zijn met master branch
$ git samenvoegen release-M.M.P
$ git tag -a M.M.P # toevoeging bericht kan ingesteld worden via -m vlag
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push oorsprong :release-M.M.P

Bugfix

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

$ Commit fixes
$ git add .
$ git commit -m "Bugfix M.M.P: Probleem essentie fix" #initial commit
$ git push origin bugfix-M.M.P

Open pull-verzoek

Wijzigingen samenvoegen en tak verwijderen

$ git checkout release-M.M.P # branch moet in dit stadium gesynchroniseerd worden met de huidige release branch
$ git samenvoegen bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push oorsprong :bugfix-M.M.P

Hotfix

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P staat voor huidige release

$ Commit fixes
$ git add .
$ git commit -m "Hotfix M.M.P: Probleem essentie fix" #initial commit
$ git push oorsprong bugfix-M.M.P

Open pull-verzoek

Wijzigingen samenvoegen, vrijgeven en branc verwijderen

$ git checkout master # branch moet in dit stadium gesynchroniseerd zijn met de huidige master
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # toevoeging bericht kan ingesteld worden via -m vlag
$ git push origin X.Y.(Z+1)
$ git push oorsprong 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

Lees meer:

• Codest's goede praktijken voor het bouwen van software: CircleCI
• Hoe maak je Google Chrome-extensies met de styler voor Netflix-ondertitels?
• React: het populairste JavaScript raamwerk