See dokument on kirjutatud selleks, et ühtlustada ettevõtte sisemisi GitFlow reegleid. See meetod ei tutvusta puhast GitFlow'd, kuna see on segu nii GitFlow'st kui ka GitLab Flow'st, mille puhul on ettevõtte parimad tavad töötatud paljude aastate jooksul. See aitab hoida repositooriumi puhta ja loetava ajaloo ning parema kontrolli muudatuste ja projekt elutsüklid.

Repositooriumi initsialiseerimine

Pärast repositooriumi initsialiseerimist loo arendada ja kapten haru, kui see ei ole vaikimisi lisatud. Arendusharu peaks sisaldama arendus kood mis on peegliks masterharu peeglile, mis sisaldab uusi funktsioone. Master sisaldab koodi stabiilset versiooni, mis esindab tootmisseisundit. Mõlemal on lõpmatu eluiga ja võrreldes teiste harudega Git Flow's ei eemaldata neid kunagi. Seadistage korralikud kaitsereeglid: nõuda pull taotluse läbivaatamist enne ühendamist ja nõuda staatuse kontrolli läbimist enne ühendamist. Samuti võite kaaluda, kas lubada ainult valitud meeskond liikmetele, et ühendada muudatused masterisse.

$ git init
$ git commit --allow-empty -m "Initial commit" (esialgne kinnitus)
$ git checkout -b develop master

MÄRKUS: Mõnikord on projekti jaoks oluline lisada rohkem lõpmatuid harusid, et näiteks esindada olemasolevaid keskkondi. Hoidke siiski võimaluse korral "kahe reeglit".

Funktsiooni harud

Kui hakkate antud funktsiooniga töötama, veenduge kõigepealt, et teil on oma arendada haru sünkroonitud.

 $ git checkout develop && git pull --rebase

Seejärel kontrollige oma funktsiooniharu. Nimetage see vastavalt antud skeemile: feature-JIRA-TASK-ID või võite ka seda reeglit rikkuda ja nimetada seda teisiti. Sel juhul veenduge, et see ei läheks vastuollu release, hotfix, bugfix, development või master branch jaoks reserveeritud mustritega. JIRA ülesande ID-de säilitamine aitab teil oma funktsiooniharusid tõhusamalt hallata.

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

See haru peaks eksisteerima nii kaua, kuni antud funktsioon on välja töötatud ja seejärel ühendatakse vanemharu. Kohalikku haru üleviimiseks järgige seda käsku:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Ülesande kirjeldus"

Soovitatav on lisada oma kohalikku harusse rohkem kommiteid, järgides reeglit "Commit early and often". Lõpuks tuleb need siiski suruda ühte JIRA ülesannet esindavasse kommitisse. Sageli kommiteerimine aitab teil oma arendusajalugu hallata. Kui funktsioon on valmis, on aeg avada Pull Request, et arendada haru. Kõigepealt võite pushida oma kohaliku haru, kui seda ei ole liiga kaugele lükatud:

 $ git push origin feature-JIRA-TASK-ID

Kui haru on valmis, avage oma tõmbetaotlus GitHubis, järgides seda artiklit: https://help.github.com/en/articles/creating-a-pull-request

Enne tõmbetaotluse avamist veenduge palun järgmises:

• a nõuetekohane kirjeldus on antud - tavaliselt oleksite linkida oma JIRA ülesanne, kuid võite lisada ka mõnda kasulikku teavet, mis on seotud kehtiva koodiga
• CircleCI sammud läbiti edukalt
• teie meeskonnaliikmed määrati - hea tava on kaasata kõik oma meeskonnaliikmed volitatud isikuteks.
• . retsensendid valiti välja - ülevaatajate arv sõltub teie meeskonnast
• teie kood on tegelikult valmis läbivaatamiseks - vaadake oma koodi veelkord üle, mõelge veelkord, kas on veel midagi refaktoorida, testige seda lokaalselt ja tagada, et see on valmis edasisteks sammudeks.
• on olemas puuduvad liitmiskonfliktid ja haru on ajakohane koos developiga - kui neid on, siis lahendage need kõigepealt

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID 1TP65Kasutage seda ettevaatlikult, kuna -f lipp kirjutab kaugrepositooriumi üle.

• hoida ainult olulised kommitid - iga commit peaks olema esindatud näiteks JIRA ülesandena, JIRA-TASK-ID: Uue funktsiooni konfiguratsioon; teised peaksid olema ümberhindamise ajal kokku surutud oma haru koos arendusharuga
• teil on valitud õige sihtkoha haru
• te ei unusta muuta oma JIRA ülesande staatust

Funktsiooni haru ühendamine

On aeg ühendada oma muudatused arendusharusse, kui:

• valitud meeskonnaliikmed kiitsid tõmbetaotluse heaks
• kõik testid on edukalt lõpetatud
• ei ole mingeid ühinemiskonflikte ja kommiteerimise ajalugu näeb hea välja

Seda võib teha kas projektijuht või funktsioonide arendaja. Ühinemise teostamiseks järgige järgmisi samme:

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

Nüüd saab JIRA ülesande staatust muuta.

Vabastab

Väljaande harud peaks looma jooksva väljaande eest vastutav isik. Tavaliselt luuakse väljalaskeid perioodiliselt, näiteks vastavalt sprint elutsükkel.

Semantiline versioonimine

Avaldamisharule õige nime ja vastava sildi andmine ei ole alguses lihtne ülesanne. Hea tava on alustada semantilise versioonimise kasutamist (https://semver.org/), mis võimaldab paremat kontrolli ja teeb git-ajaloo lugemise lihtsamaks. Versioonijada ehitatakse vastavalt skeemile MAJOR.MINOR.PATCH:

• MAJOR - muudatus, mis kujutab endast ühildumatuid API muudatusi
• MINOR - uute funktsioonide lisamine tagasiulatuvalt ühilduvana
• PATCH - tagurpidi ühilduvate vigade paranduste lisamine

Võite kasutada ka spetsiaalseid järelliiteid, näiteks neid, mis tähistavad beeta- või pärandharusid, või luua eelväljaandeid. Sellisel juhul nimetage see korralikult, nt 1.1.0-beta.4, 1.1.0-beta.5 või 1.1.0-alpha.

Vabastamise tegemine

Väljaandmisharu peaks olema arenduse filiaal ja see võiks sisaldada ainult veaparandustega seotud kommiteid.

Haru nimi peaks põhinema versioonil, mille eesliide on release-: release-MAJOR.MINOR.PATCH. Väljaandmise haru peaks olema täielikult testitud nii automaatselt kui ka käsitsi kohta lavastuskeskkond. Kui vead tekivad, on see viimane võimalus korralike paranduste tegemiseks ja kogu protsessi uuesti käivitamiseks, kuni see ei ole positiivselt kontrollitud ja valmis edasiseks töötlemiseks. Seejärel tuleks pushida release commit, koos praeguse release versiooni stringi muudatustega failides, näiteks package.jsonis. See peaks mõjutama ka CHANGELOG.md faili. See aitab teil jälgida kõiki muudatusi enne korralikku vabastamist ja valmistada sisu ette GitHubi vabastamiseks, kui ühendamisprotsess on lõpetatud. Ühe faili värskendus peaks koosnema kõigist väljalaske muudatustest, mis on rühmitatud kolme kategooriasse: funktsioonid, parandused ja hooldus.

Esimeses etapis veenduge, et nii develop- kui ka master-haru on ajakohased.

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

Siinkohal võib otsustada luua teise tõmbetaotluse masterile koos release-haruga. Võib olla hea mõte teha täiendav kontroll, kui kõik testid läbivad hästi kaugemas masinas.

$ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # lisateade võib olla seatud lipuga -m
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Seejärel minge GitHubi avalduste lehele ja vajutage nuppu "Draft new release". Valige kuvatavas vormis praeguse versiooni silt, määrake väljaande pealkiri, mis sarnaneb väljaande kommiteerimisele (Product Name M.M.P release), ja korralik kirjeldus, mis põhineb failil CHANGELOG.md. Avalike projektide puhul peaks kirjeldus sisaldama loetelu kõigist praeguses versioonis sisalduvatest PR-dest.

Kui mõned veaparandused on rakendatud release-harule, veenduge, et olete oma arendusharu uuendanud:

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

Hotfixid ja veaparandused

Peamine erinevus vigade ja kuumade paranduste vahel on nende sihtharud.

Vigade parandamine

Vigade parandamine peaks olema ainus viis koodi uuendamiseks enne selle ühendamist masterisse. Kõigepealt looge haru praegusest funktsiooniharust. Veenduge, et see on lokaalselt ajakohane.

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

Seejärel tehke vajalikud muudatused. Kui protsess on lõpetatud, looge pull request ja suunake see release-harule. Järgige juhiseid funktsiooniharu osas. Teie lõpliku commit'i pealkiri peaks vastama antud skeemile: "Bugfix M.M.P: Problem essence fix". Kui pull request on heaks kiidetud, on aeg see praegusesse release'ile ühendada.

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

Hotfix

Selleks, et teha hotfixi master-harule, tuleb teha väga sarnaseid samme nagu veaparanduse puhul, pidades silmas, et sihtharu on nüüd master-haru.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P esindab praegust väljaannet

Seejärel järgige tavapäraseid arendusetappe ja kui protsess on lõppenud, looge pull request, mille sihtmärgiks on master-haru. Pidage meeles, et lõplik commit peaks vastama antud skeemile "Hotfix X.Y.(Z + 1): Problem essence fix". Kui iga kontrollpunkt on edukalt läbitud, tehke ühinemine masterisse. Need sammud erinevad veaparanduse puhul esitatud sammudest, kuna meil on vaja bumpida praegune versioon.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # lisateade võib olla seatud lipuga -m
 $ 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

Spikker

Init repositoorium

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

Omadused

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

Alustage oma arendustegevust ja commits

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

Avatud tõmbetaotlus

Rebase ja valmistada pull request ette

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID 1TP65Kasutage seda ettevaatlikult, kuna -f lipp kirjutab kaugrepositooriumi üle.

Muudatuste ühendamine ja haru kustutamine

$ git checkout develop # haru peaks selles etapis olema sünkroonitud develop haruga.
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Vabastab

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

Loo väljalaskekommitatsioon

$ git add .
$ git commit -m "Toote nimi M.M.P release" #initial commit
$ git push origin release-M.M.P

Avatud tõmbetaotlus

Muudatuste ühendamine, vabastamine ja haru kustutamine

$ git checkout master # haru peaks selles etapis olema sünkroonitud master haruga.
$ git merge release-M.M.P
$ git tag -a M.M.P # lisateade võib olla seatud lipuga -m
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Vigade parandamine

$ 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: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Avatud tõmbetaotlus

Muudatuste ühendamine ja haru kustutamine

$ git checkout release-M.M.P # haru peaks selles etapis olema sünkroonitud praeguse release haruga.
$ 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 esindab praegust versiooni.

$ Commit parandused
$ git add .
$ git commit -m "Hotfix M.M.P: Probleemi olemuse parandamine" #initial commit
$ git push origin bugfix-M.M.P

Avatud tõmbetaotlus

Muudatuste ühendamine, vabastamine ja kustutamine

$ git checkout master # haru peaks selles etapis olema sünkroonitud praeguse masteriga.
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # lisateade võib olla seatud lipuga -m
$ 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

Loe edasi:

• Codesti hea tava tarkvara loomiseks: CircleCI
• Kuidas luua Google Chrome'i laiendusi, kasutades Netflixi subtiitrite stiiliprogrammi?
• React: kõige populaarsem JavaScript raamistik