Komponenty toku GitHubu

  • 8 min

V této lekci se podíváme na následující komponenty toku GitHubu:

  • Větve
  • Zápisy
  • Žádosti o přijetí změn
  • Pracovní postup GitHubu
  • Git flow

Komponenty služby GitHub Flow

Než se pustíme do pracovních postupů specifických pro GitHub, je užitečné pochopit, že GitHub Flow vychází přímo ze základních konceptů Gitu.

Git poskytuje nástroje ke sledování a správě změn v kódu v průběhu času. GitHub na tom staví tím, že usnadňuje používání těchto nástrojů s funkcemi, jako jsou větve, potvrzení, žádosti o přijetí změn a vizuální rozhraní pro spolupráci. Začněme tím, že se podíváme, jak tyto koncepty fungují na GitHubu.

Co jsou větve

V poslední části jsme vytvořili nový soubor a novou větev ve vašem úložišti.

Větve jsou základní součástí prostředí GitHubu. Umožňují provádět změny, aniž by to mělo vliv na výchozí větev.

Vaše větev je bezpečné místo pro experimentování s novými funkcemi nebo opravami. Pokud uděláte chybu, můžete vrátit změny nebo provést další změny, abyste chybu opravili. Změny se ve výchozí větvi neaktualizují, dokud větev nesloučíte.

Poznámka:

Alternativně můžete vytvořit novou větev a přepnout na ni pomocí gitu v terminálu. Příkaz by byl git checkout -b newBranchName

Co jsou commity

V předchozí lekci jste do úložiště přidali nový soubor vložením potvrzení. Pojďme krátce prozkoumat, co jsou to commits.

Commit je změna jednoho nebo více souborů ve větvi. Každé potvrzení se sleduje jedinečným ID, časovým razítkem a přispěvatelem bez ohledu na to, jestli se provádí přes příkazový řádek nebo přímo ve webovém rozhraní GitHubu. Potvrzení poskytují jasnou auditní stopu pro každého, kdo přezkoumává historii souboru nebo propojené položky, jako je například úkol nebo pull request.

Potvrzení můžete vytvořit pomocí Gitu v terminálu pomocí:

git commit -m "Add a helpful commit message"

Snímek obrazovky se seznamem commitů GitHubu do hlavní větve.

V úložišti Git může soubor existovat v několika platných stavech, protože prochází procesem správy verzí. Primární stavy souboru v úložišti Git jsou nesledované a sledované.

Nesledované: Počáteční stav souboru, pokud ještě není součástí úložiště Git. Git neví o své existenci.

Sledovaný: Sledovaný soubor je takový, který Git aktivně monitoruje. Může být v jednom z následujících podstavů:

  • Nezměněný: Soubor se sleduje, ale od posledního potvrzení se nezměnil.
  • Upravený: Soubor byl změněn od posledního potvrzení, ale tyto změny ještě nejsou připravené pro další potvrzení.
  • Připraveno: Soubor byl změněn a změny byly přidány do indexu (označovaného také jako index). Tyto změny jsou připravené k potvrzení.
  • Commitováno: Soubor je v databázi repozitáře. Představuje nejnovější potvrzenou verzi souboru.

Tyto stavy pomáhají vašemu týmu pochopit stav každého souboru a kde se nachází v procesu správy verzí.

Co jsou žádosti o přijetí změn?

Pull request je mechanismus, který slouží k signalizaci, že commity z jedné větve jsou připraveny ke sloučení s jinou větví.

Člen týmu, který odešle žádost o přijetí změn , požádá jednoho nebo více revidujících, aby ověřil kód a schválil sloučení. Tito kontroloři mají možnost komentovat změny, přidat vlastní změny nebo použít žádost o přijetí změn k další diskusi.

GitHub také podporuje návrhy žádostí o přijetí změn, které vám umožní otevřít žádost, která ještě není připravená ke kontrole.

Po schválení změn (v případě potřeby) se zdrojová větev žádosti o přijetí změn (porovnávaná větev) sloučí do základní větve.

Snímek obrazovky s žádostí o přijetí změn a komentářem v rámci žádosti o přijetí změn

Nyní, když jste viděli, jak fungují větve, potvrzení a pull requesty, se podíváme na to, jak se spojují v GitHub Flow.

Pracovní postup GitHubu

Snímek obrazovky znázorňující vizuální znázornění toku GitHubu v lineárním formátu, který zahrnuje novou větev, potvrzení, žádost o přijetí změn a sloučení změn zpět na hlavní v daném pořadí

Tok GitHubu je jednoduchý pracovní postup, který vám pomůže bezpečně provádět a sdílet změny. Je to výborné pro vyzkoušení nápadů a spolupráci s týmem pomocí větví, pull requestů a sloučování.

Poznámka:

GitHub flow je jedním z několika oblíbených pracovních postupů. Mezi další patří Git flow a trunk-based development.

Teď, když víme základy GitHubu, můžeme projít tok GitHubu a jeho komponenty.

  1. Začněte vytvořením větve, aby vaše změny, funkce nebo opravy neovlivní hlavní větev.
  2. V dalším kroku proveďte aktualizace ve větvi. Pokud ho pracovní postup podporuje, můžete před sloučením nasadit změny z této větve a otestovat je.
  3. Teď vytvořte pull request, pro vyžádání zpětné vazby a zahájení revize.
  4. Pak si projděte komentáře a proveďte potřebné aktualizace na základě zpětné vazby vašeho týmu.
  5. Jakmile budete mít jistotu ve svých změnách, získejte schválení a sloučte pull request do hlavní větve.
  6. Potom odstraňte větev, aby bylo úložiště čisté, a vyhněte se používání zastaralých větví.

Git flow

I když je GitHub Flow jednoduchý pracovní postup navržený pro průběžné doručování, jedná se o strukturovanější model větvení, který se často používá v prostředích řízených verzemi. Tok Git flow existuje déle než GitHub Flow a termín master může být stále používán místo main jako výchozí větev.

Nvieův diagram modelu větvení Gitu zobrazující větve funkcí, vývojovou větev, větve vydané verze, opravy hotfix a hlavní větev v průběhu času Barevné uzly potvrzení a šipky znázorňují, jak se funkce sloučí do vývoje, jak se vytvářejí větve vydaných verzí pro verzi 1.0, jak se opravy chyb vrací do vývoje a jak se opravy hotfix použijí přímo na hlavní server. Značky označují vydané verze 0.1, 0.2 a 1.0.

Obrázek Vincenta Driessena z úspěšného modelu větvení Gitu

Typy větví Git flow

Git flow používá několik dlouhodobých a dočasných větví:

  • master: Vždy odráží kód připravený pro produkční prostředí.
  • develop: Obsahuje nejnovější vývojovou práci pro příští verzi.
  • funkce/*: Používá se k vytváření nových funkcí; větvené z develop a sloučené zpět po dokončení.
  • release/*: Připraví novou produkční verzi z develop; umožňuje konečné testování a menší opravy chyb.
  • hotfix/*: Používá se k rychlé opravě problémů v produkci; odvětvené z master.

Jak probíhá Git Flow proces

  1. Vývojáři vytvářejí funkční větve z develop, aby vytvořili novou funkčnost.
  2. Když je čas na vydání, vytvoří se větev vydané verze z develop. To izoluje přípravu verzí před vydáním, aby vývoj mohl pokračovat bez přerušení.
  3. Opravy chyb je možné přidat do větve vydané verze, ale hlavní funkce by měly čekat na budoucí verzi.
  4. Po dokončení se větev vydané verze sloučí do master a označí se číslem verze. GitHub může tyto značky použít k vytvoření poznámek k vydání.
  5. Stejná větev vydané verze by se měla sloučit zpět develop , aby byla synchronizovaná.
  6. Pokud dojde k kritické produkční chybě, je vytvořena hotfixová větev z master. Po opravení se sloučí do master i develop.

Kdy použít Git flow

  • Nejvhodnější pro projekty s naplánovanými nebo verzovanými vydáními
  • Užitečné, pokud udržujete více produkčních verzí (např. větve dlouhodobé podpory)
  • Ideální pro pomalejší, strukturovanější vývojové cykly (např. podniková nebo regulovaná prostředí)
  • Vzhledem k dalšímu řízení větví se považuje za robustnější ve srovnání s GitHub Flow.

Poznámka:

Git flow předpokládá slučovací commity pro integraci větví. Použití rebase nebo squash merges může narušit strukturu větve a sledování historie.

Pro mnoho týmů, které používají GitHub, je GitHub Flow jednodušší a rychlejší. Pokud ale váš tým ocení předvídatelnost a potřebuje více plánování vydání verzí, může být Git flow vhodnější.

Gratulujeme! Právě jste prošli úplným tokem GitHubu a prozkoumali jste, jak tok Git nabízí strukturovanou alternativu pro projekty řízené verzemi.

Pojďme přejít na další část, kde se podíváme na rozdíly mezi problémy a diskuzemi.