Tento dokument byl sepsán za účelem sjednocení interních firemních pravidel GitFlow. Tato metoda nezavádí čistý GitFlow, protože je kombinací GitFlow i GitLab Flow s osvědčenými firemními postupy vypracovanými v průběhu mnoha let. Pomáhá udržovat čistou a čitelnou historii repozitáře a lepší kontrolu nad změnami a projekt životních cyklů.

Inicializace úložiště

Po inicializaci úložiště vytvořte položku rozvíjet a master větev, pokud nebyla zahrnuta ve výchozím nastavení. Větev develop by měla obsahovat vývojovou větev kód která je zrcadlem větve master s novými funkcemi. Hlavní větev obsahuje stabilní verzi kódu, která představuje produkční stav. Obě mají nekonečnou dobu životnosti a ve srovnání s ostatními větvemi ve službě Git Flow nebudou nikdy odstraněny. Nastavte správná pravidla ochrany: vyžadovat recenze požadavků na stažení před sloučením a vyžadovat, aby před sloučením proběhly kontroly stavu. Můžete také zvážit povolení pouze vybraných tým členové sloučit změny do hlavní verze.

$ git init
$ git commit --allow-empty -m "Počáteční revize"
$ git checkout -b develop master

POZNÁMKA: Někdy je pro projekt důležité přidat více nekonečných větví, například pro zastoupení dostupných prostředí. Pokud je to však možné, zachovejte "pravidlo dvou".

Funkce větví

Když začínáte pracovat s danou funkcí, nejprve se ujistěte, že jste si rozvíjet synchronizovaná větev.

 $ git checkout develop && git pull --rebase

Poté se podívejte do své větve funkcí. Pojmenujte ji podle daného schématu: feature-JIRA-TASK-ID nebo můžete toto pravidlo porušit a pojmenovat jej jinak. V takovém případě se ujistěte, že není v rozporu se vzory vyhrazenými pro release, hotfix, bugfix, development nebo hlavní větev. Zachování ID úkolů JIRA vám pomůže efektivněji spravovat větve funkcí.

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

Tato větev by měla existovat tak dlouho, dokud je daná funkce vyvíjena a poté sloučena do nadřazené větve. Chcete-li odevzdat do místní větve, postupujte podle tohoto příkazu:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Popis úkolu"

Doporučujeme přidávat do místní větve více revizí podle pravidla "odevzdávat brzy a často". Nakonec však musí být vtěsnány do jediné revize představující úlohu JIRA. Časté odevzdávání vám pomůže spravovat historii vývoje. Jakmile je funkce hotová, je čas otevřít požadavek Pull Request pro vývoj větve. Nejprve můžete odeslat svou lokální větev, pokud nebyla odeslána příliš daleko:

 $ git push origin feature-JIRA-TASK-ID

Když je větev připravena, otevřete žádost o stažení na GitHubu podle tohoto článku: https://help.github.com/en/articles/creating-a-pull-request

Před otevřením žádosti o stažení se ujistěte, že:

• a správný popis byla poskytnuta - obvykle byste měli propojte svou úlohu JIRA, ale můžete také uvést některé užitečné informace týkající se aktuálního kódu.
• CircleCI kroky byly úspěšně splněny
• vaše členové týmu byli přiděleni - je dobré zahrnout všechny členy týmu jako příjemce.
• na byli vybráni recenzenti - počet recenzentů závisí na vašem týmu
• váš kód je skutečně připraven ke kontrole - naposledy se podívejte na svůj kód, znovu si rozmyslete, zda je ještě něco k refaktorizaci, otestujte to lokálně. a zajistit, aby byl připraven k dalším krokům.
• existují žádné konflikty při slučování a větev je aktualizována pomocí develop. - pokud existují, nejprve je vyřešte

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # použít příznak -i pro squash
$ git push -f origin feature-JIRA-TASK-ID #ento příkaz používejte opatrně, protože příznak -f přepíše vzdálený repozitář.

• zachovat pouze důležité revize - každá revize by měla být reprezentována například úlohou JIRA, JIRA-TASK-ID: Konfigurace nové funkce; ostatní by měli být rozmáčknuto při přepočítávání vaší větve s větví develop
• máte k dispozici vybrána správná cílová větev
• nezapomínáte na změnit stav úlohy JIRA

Sloučení větve funkcí

Je čas sloučit změny do vývojové větve, když:

• požadavek na stažení byl schválen vybranými členy týmu
• všechny testy byly úspěšně dokončeny
• neexistují žádné konflikty při slučování a historie revizí vypadá v pořádku.

To může provést buď vedoucí projektu, nebo vývojář funkce. Chcete-li provést sloučení, postupujte podle následujících kroků:

 $ 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

Nyní lze stav úlohy JIRA změnit.

Uvolňuje

Větve vydání by měla vytvářet osoba odpovědná za aktuální vydání. Obvykle se verze vytvářejí periodicky, např. podle pokynů sprint životní cyklus.

Sémantické verzování

Přidělit větvi vydání správný název a odpovídající značku není na samém začátku snadný úkol. Dobrou praxí je začít používat sémantické verzování (https://semver.org/), což umožňuje lepší kontrolu a usnadňuje čtení historie git. Řetězec verzí je konstruován podle schématu MAJOR.MINOR.PATCH:

• MAJOR - změna představující nekompatibilní změny API
• MINOR - přidání nových funkcí zpětně kompatibilním způsobem
• PATCH - přidání zpětně kompatibilních oprav chyb

Můžete také používat speciální přípony, například přípony označující beta nebo starší větve, nebo vytvářet předběžné verze. V takovém případě je správně pojmenujte, např. 1.1.0-beta.4, 1.1.0-beta.5 nebo 1.1.0-alpha.

Uvolnění

Větev release by měla být potomkem větve develop a mohla by obsahovat pouze revize spojené s opravami chyb.

Název větve by měl vycházet z verze vydání s předponou release-: release-MAJOR.MINOR.PATCH. Větev pro vydání by měla být plně testováno automaticky i ručně na stagingové prostředí. Pokud se vyskytnou chyby, je to poslední možnost, jak prosadit správné opravy a celý proces spustit znovu, dokud nebude pozitivně zkontrolován a připraven k dalšímu zpracování. Poté by měla být odeslána revize vydání se změnami řetězce aktuální verze vydání v souborech, jako je package.json. Mělo by to mít dopad i na soubor CHANGELOG.md. To vám pomůže sledovat všechny změny před řádným vydáním a připravit obsah pro vydání v systému GitHub po dokončení procesu slučování. Aktualizace jednoho souboru by měla obsahovat všechny změny pro vydání seskupené do tří kategorií: funkce, opravy a údržba.

V prvním kroku se však ujistěte, že máte aktualizované obě větve develop i master.

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

V tomto okamžiku se můžete rozhodnout vytvořit další požadavek na stažení do masteru s větví release. Může být dobré provést dodatečnou kontrolu, zda všechny testy na vzdáleném počítači proběhly v pořádku.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # příznakem -m lze nastavit zprávu o přidání.
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Poté přejděte na stránku GitHub releases a stiskněte tlačítko "Draft new release". V zobrazeném formuláři vyberte značku aktuální verze, nastavte název vydání podobný revizi vydání (Product Name M.M.P release) a správný popis podle souboru CHANGELOG.md. U veřejných projektů by měl popis obsahovat seznam všech PR obsažených v aktuální verzi.

V případě, že byly ve větvi release použity některé opravy chyb, zajistěte aktualizaci vývojové větve:

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

Opravy a opravy chyb

Hlavním rozdílem mezi chybou a hot fixem je jejich cílová větev.

Oprava chyb

Opravy chyb by měly být jedinou formou aktualizace kódu před začleněním do masteru. Nejprve vytvořte větev z aktuální větve funkcí. Ujistěte se, že ji máte lokálně aktualizovanou.

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

Poté odevzdejte potřebné změny. Po dokončení procesu vytvořte požadavek na stažení a nasměrujte jej do větve pro vydání. Postupujte podle pokynů v části větev funkcí. Váš konečný název revize by měl odpovídat zadanému schématu: "Bugfix M.M.P: Problem essence fix". Jakmile je požadavek na stažení schválen, je čas jej začlenit do aktuálního vydání.

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

Hotfix

Chcete-li provést opravu hotfix na hlavní větvi, je třeba provést velmi podobné kroky jako při opravě chyby, přičemž je třeba mít na paměti, že cílovou větví je nyní hlavní větev.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P představuje aktuální vydání

Poté postupujte podle obvyklých kroků vývoje a po dokončení procesu vytvořte požadavek na stažení s cílovou větví master. Mějte na paměti, že konečná revize by měla odpovídat zadanému schématu "Hotfix X.Y.(Z + 1): Oprava podstaty problému". Jakmile každý kontrolní bod úspěšně projde, proveďte sloučení do větve master. Tyto kroky se liší od kroků uvedených pro opravu chyby, protože je potřeba překlopit aktuální verzi vydání.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # příznakem -m lze nastavit zprávu o doplnění.
 $ 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

Kontrolní list

Úložiště init

 $ git init
 $ git commit --allow-empty -m "Počáteční revize"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Funkce

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

Spuštění vývoje a revizí

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

Otevřít požadavek na stažení

Přebalení a příprava žádosti o stažení

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # použít příznak -i pro squash
$ git push -f origin feature-JIRA-TASK-ID #uto volbu používejte opatrně, protože příznak -f přepíše vzdálený repozitář.

Sloučení změn a odstranění větve

$ git checkout develop # větev by měla být v této fázi synchronizována s větví 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

Uvolňuje

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

Vytvoření revize vydání

$ git add .
$ git commit -m "Product Name M.M.P release" #initial commit
$ git push origin release-M.M.P

Otevřít požadavek na stažení

Sloučení změn, vydání a odstranění větve

$ git checkout master Větev # by měla být v této fázi synchronizována s větví master.
$ git merge release-M.M.P
$ git tag -a M.M.P # zprávu o přidání lze nastavit pomocí příznaku -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

Oprava chyb

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

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

Otevřít požadavek na stažení

Sloučení změn a odstranění větve

$ git checkout release-M.M.P Větev # by měla být v této fázi synchronizována s aktuální větví release.
$ 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 představuje aktuální vydání

$ Opravy odevzdat
$ git add .
$ git commit -m "Hotfix M.M.P: Oprava podstaty problému" #initial commit
$ git push origin bugfix-M.M.P

Otevřít požadavek na stažení

Sloučení změn, uvolnění a odstranění větví

$ git checkout master Větev # by měla být v této fázi synchronizována s aktuální větví master.
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # příznakem -m lze nastavit zprávu o doplnění.
$ 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

Přečtěte si více:

• Správné postupy pro tvorbu softwaru společnosti Codest: CircleCI
• Jak vytvořit rozšíření pro Google Chrome pomocí styleru titulků Netflix?
• React: nejoblíbenější rámec JavaScript