Git 🌙
Chapters ▾ 2nd Edition

5.1 Distribuovaný Git - Distribuované pracovní postupy

Máte vytvořen vzdálený gitový repozitář, který je nastaven tak, aby mohli všichni vývojáři sdílet svůj zdrojový kód, a znáte základní příkazy Gitu pro práci v lokálním prostředí. Nastal čas, abychom se podívali na využití některých distribuovaných pracovních postupů, které vám Git nabízí.

V této kapitole uvidíte, jak se v distribuovaném prostředí s Gitem pracuje v roli přispěvatele a v roli integrátora. Jinými slovy, naučíte se, jak lze do projektu úspěšně přidat vlastní kód, jak to co nejvíc usnadnit sobě i správci projektu a také to, jak se dá úspěšně udržovat projekt, do kterého přispívá velký počet vývojářů.

Distribuované pracovní postupy

Na rozdíl od centralizovaných systémů pro správu verzí, distribuovaný charakter systému Git umožňuje vývojářům mnohem větší pružnost ve způsobech spolupráce na projektech. V centralizovaných systémech představuje každý vývojář samostatný uzel, pracující s centrálním úložištěm více či méně na stejné úrovni. Naproti tomu v Gitu je každý vývojář potenciálním uzlem i úložištěm. To znamená, že každý vývojář může přispívat kódem do ostatních repozitářů a současně může spravovat veřejný repozitář, z kterého mohou ostatní vycházet při své práci a do kterého mohou přispívat. Tím se pro váš projekt a váš tým otvírá široké spektrum pracovních postupů. Podíváme se na pár obvyklých přístupů, které dané pružnosti využívají. Uvedeme si jejich přednosti i eventuální slabiny. Můžete vybrat jeden z nich, nebo je můžete pro dosažení požadovaných vlastností navzájem kombinovat.

Centralizovaný pracovní postup

V centralizovaných systémech je většinou možný pouze jediný model, tzv. centralizovaný pracovní postup. Jedno centrální úložiště (hub) nebo repozitář přijímá zdrojový kód a každý podle něj synchronizuje svou práci. Několik vývojářů představuje uzly — konzumenty centrálního úložiště --, které se synchronizují se podle tohoto místa.

Centralizovaný pracovní postup.
Figure 54. Centralizovaný pracovní postup.

To znamená, že pokud dva vývojáři klonují z centrálního úložiště a oba provedou změny, pak jen první z nich může bez problémů odeslat (push) své změny zpět. Druhý vývojář musí před odesláním svých změn začlenit (merge) práci prvního vývojáře do své, aby nepřepsal jeho změny. Tento koncept platí jak pro Git, tak pro Subversion (nebo pro jiný systém pro správu verzí). Bez problémů funguje i v Gitu.

Pokud už jste ve své firmě nebo v týmu na centralizovaný pracovní postup zvyklí, můžete v něm snadno pokračovat i při použití Gitu. Jednoduše vytvořte repozitář a přidělte všem ze svého týmu oprávnění k odesílání dat. Git uživatelům neumožní, aby se navzájem přepisovali. Dejme tomu, že John i Jessica začnou pracovat ve stejném čase. John dokončí své úpravy a odešle je na server. Poté se Jessica pokusí odeslat své změny, ale server je odmítne. Řekne jí, že se pokouší odeslat změny (push), které nemají charakter „rychle vpřed“, a že to nebude moci udělat, dokud neprovede vyzvednutí a sloučení (fetch a merge). Tento pracovní postup je pro mnoho lidí zajímavý, protože je to model, který jsou zvyklí používat a jsou s ním spokojeni.

A není také omezen jen na malé týmy. Model větvení Gitu umožňuje, aby na jednom projektu pracovaly stovky vývojářů a využívali při tom souběžně desítky větví.

Pracovní postup s integračním manažerem

Protože Git umožňuje práci s více vzdálenými repozitáři, lze využít pracovní postup, kdy má každý vývojář přiděleno právo zápisu do svého vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden hlavní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvoříte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté můžete správci hlavního projektu odeslat žádost, aby do projektu vaše změny vtáhl (pull). Správce si pak může váš repozitář přidat jako vzdálený, lokálně otestovat vaše změny, začlenit (merge) je do své větve a odeslat zpět (push) do svého repozitáře. Proces funguje následovně (viz obrázek Pracovní postup s integračním manažerem.):

  1. Správce projektu odešle data do svého veřejného repozitáře.

  2. Přispěvatel naklonuje tento repozitář a provede změny.

  3. Přispěvatel odešle změny do své vlastní veřejné kopie.

  4. Přispěvatel pošle správci email, ve kterém jej požádá o vtažení změn (pull).

  5. Správce si přidá přispěvatelův repozitář jako vzdálený a provede lokální sloučení (merge).

  6. Správce odešle začleněné změny do hlavního repozitáře.

Pracovní postup s integračním manažerem.
Figure 55. Pracovní postup s integračním manažerem.

Tento pracovní postup je velmi běžný, pokud se pracuje centralizačními nástroji[15] jako je GitHub nebo GitLab. Projekt se zde dá snadno odštěpit a změny se pak odesílají do vlastní, odštěpené části, kde se na ně může každý podívat. Jednou z hlavních výhod tohoto přístupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může vaše změny do projektu vtáhnout (pull in) až to uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu — všichni zúčastnění mohou pracovat svým vlastním tempem.

Pracovní postup s diktátorem a poručíky

Jedná se o variantu pracovního postupu s více repozitáři. Většinou se používá u obřích projektů se stovkami spolupracovníků. Možná nejznámějším příkladem je vývoj jádra Linuxu. Za konkrétní části repozitáře odpovídají různí integrační manažeři. Říká se jim poručíci (lieutenants). Všichni poručíci mají jednoho integračního manažera, kterému se říká benevolentní diktátor. Repozitář benevolentního diktátora slouží jako referenční repozitář, z nějž všichni spolupracovníci musí stahovat data. Proces funguje nějak takto (viz obrázek Pracovní postup s benevolentním diktátorem.):

  1. Stálí vývojáři pracují na svých tématických větvích a přeskládávají (rebase) svou práci na vrchol větve master. Větev master je předmětem zájmu diktátora.

  2. Poručíci začleňují (merge) tématické větve vývojářů do svých větví master.

  3. Diktátor začleňuje větve master poručíků do své větve master.

  4. Diktátor odesílá svou větev master do referenčního repozitáře, aby ji ostatní vývojáři mohli použít jako základ pro přeskládání (rebase).

Pracovní postup s benevolentním diktátorem.
Figure 56. Pracovní postup s benevolentním diktátorem.

Tento typ pracovního postupu sice není běžný, ale může být užitečný u velmi velkých projektů nebo v přísně hierarchických prostředích. Umožňuje vedoucímu projektu (diktátorovi) velkou část práce delegovat a poté na více místech sesbírat velké podmnožiny kódu, které pak dává dohromady.

Shrnutí pracovních postupů

Toto jsou tedy některé z běžně používaných pracovních postupů, které umožňují distribuované systémy, jako je Git. Ale sami vidíte, že lze uplatnit řadu variací, aby to vyhovovalo vašim konkrétně používaným pracovním postupům. Teď už si (snad) dokážete vybrat, jaká kombinace by vám mohla vyhovovat. Ukážeme si pár konkrétnějších příkladů toho, jak splnit hlavní role, které různé pracovní postupy vytvářejí. V následující podkapitole se dozvíte o několika obvyklých způsobech přispívání do projektu.

15. hub-based tools
scroll-to-top