Vyberte správnou strategii větvení Git

Autor: Monica Porter

Datum Vytvoření: 21 Březen 2021

Datum Aktualizace: 17 Smět 2024

Obsah

Začněte jednoduše s tokem GitHub
Větve prostředí
Značení pomocí značek
Sloučit potvrzení nebo ne?
Rychlý posun vpřed
Strategie větvení

Git je fantastický nástroj. Nástroje pro řízení zdrojů poskytují několik důležitých funkcí: místo pro uchovávání kódu, historii změn a informace o tom, kdo co kdy udělal. Pokud se vám a vašemu týmu daří se zprávami o potvrzení, můžete dokonce získat bonusové informace o tom, proč byla změna provedena. Distribuované nástroje jako Git a Mercurial také nabízejí mnoho možností pro spolupráci mezi více repozitáři a také poskytují efektivní způsoby práce s pobočkami.

Co přesně je tedy pobočka v Gitu? Podívejte se na obrázek 1. Pobočka v Gitu je jednoduše ukazatel na potvrzení. Pokud se podíváte na to, jak je pobočka zastoupena v adresáři '.git', najdete textový soubor se stejným názvem jako větev, který jednoduše obsahuje identifikátor potvrzení aktuálního 'tipu' nebo nejnovějšího potvrzení v této větvi . Samotná větev je vytvořena sledováním původu tohoto jediného potvrzení, protože každý potvrzení ví, ke kterému potvrzení došlo později.

Jako trenéra se mě vždy ptají na to, co je „správná“ strategie větvení Git. Moje rada se velmi liší v závislosti na týmu a situaci, ale existují některé běžné vzorce, které se znovu a znovu objevují. Tento příspěvek popisuje tyto vzorce a vysvětluje situace, kdy mohou být nejvíce užitečné.

Začněte jednoduše s tokem GitHub

GitHub Flow, proslavený příspěvkem na blogu od Scotta Chacona, je moje oblíbená strategie větvení. Proč? Většinou proto, že je to jednoduché a přitom pokrýt všechny základní základy. GitHub Flow jednoduše uvádí, že při práci na jakékoli funkci nebo opravě chyby byste měli vytvořit větev.

Po dokončení je sloučena zpět do hlavní jednotky se slučovacím potvrzením. Je to velmi snadný způsob, jak mohou týmy a jednotlivci bezpečně vytvářet a spolupracovat na samostatných funkcích a jak je mohou dodat, až budou hotovi. Vytvoří graf, který vypadá podobně jako na obrázku 2.

Tyto „tematické“ větve mohou mít poměrně dlouhou životnost, ale mějte na paměti, že čím více se větev odchyluje od pána, tím je pravděpodobnější, že dojde ke konfliktům, když funkce přistane. Pravidlem je, že hlavní větev je vždy nasaditelná, takže funkce musí být dokončeny a důkladně otestovány, než budou sloučeny. Po sloučení nové funkce do hlavní je normální okamžitě nasadit novou základnu kódu. K tomu můžete buď vytvořit skutečný přístup k nepřetržitému nasazení, nebo jen nastavit snadný automatizovaný proces nasazení, aby bylo možné kód nasadit často.

Na blogu Laury Thomsonové je skvělý článek, který to popisuje jako „potenciálně nepřetržité nasazení“. Nasazení kódu na živé platformy vícekrát denně se nepovažuje za neobvyklé.

Jelikož tento model prosazuje větvení i pro „opravu hotfix“ - rychlou změnu s jediným potvrzením - vytváří si vlastní grafový vzor. Obrázek 3 představuje příklad, kdy existuje pouze jednosměrné odklonění směru vývoje.

Proč by někdo vytvořil jeden závazek na větvi a poté jej sloučil se slučovacím potvrzením, spíše než jen použít změnu přímo na hlavní? Odloučení má několik filozofických důvodů, ale pro mě existují dvě hlavní výhody.

Za prvé, vytvoření pobočky dává příležitost otevřít požadavek na vyžádání a získat nějakou kontrolu / zpětnou vazbu / kontrolu kvality před změnou před sloučením. Zadruhé, pokud chcete buď zrušit sloučení změny, nebo použít stejnou změnu jinde, obě tyto věci jsou jednodušší s větví než s přímým potvrzením.

Větve prostředí

To je to, co bych rád nazval modelem „Branch per Platform“. Kromě hlavní větve existují větve, které sledují živou platformu, a další platformy, které používáte ve svém pracovním toku (například test, staging a integrace). Chcete-li to provést, hlavní zůstane na okraji vašeho projektu, ale po dokončení funkcí se odpovídajícím způsobem spojí s ostatními platformami (viz obrázek 4).

Výhodou toho je, že vždy máte větev, která sleduje konkrétní platformu, což velmi usnadňuje opravu problému, pokud je například na živém místě. Použitím živé větve jako základu vaší opravy můžete snadno nasadit stávající základ kódu plus jednu jedinou změnu. Jakmile je živá platforma vyřešena, můžete opravu použít na hlavní a další větve prostředí. To znamená, že se vyhnete situaci, kdy se snažíte uhodnout, co je na živé platformě, nebo děláte divnou opravu přímo naživu!

Značení pomocí značek

Velmi podobnou alternativou je použití značek k označení vašich verzí, když je vytváříte. Tímto způsobem se můžete podívat zpět na historii verzí, které byly aktivní. GitHub má pro to dokonce vyhrazenou stránku. Tato technika se používá zejména k označování verzí knihoven.

Jiné nástroje, například Composer pro PHP, použijí značky k vyzvednutí a zpřístupnění nově vydané verze, takže je důležité, aby se značky používaly správně. Značky mohou být také užitečné ve vašich vlastních projektech, například při konfiguraci nástrojů pro sestavení nebo nasazení tak, aby reagovaly pouze na konkrétně pojmenované značky, nikoli na každé potvrzení ve větvi nebo na celé úložiště.

Sloučit potvrzení nebo ne?

Používání Gitu nám dává možnost sloučit změny v libovolném pořadí, bez ohledu na to, jak byly tyto funkce skutečně vytvořeny a kombinovány. Umožňuje nám také přepsat historii, což vede k nekonečným debatám o výhodách čistého a hezkého grafu odevzdání, oproti té, která odráží to, co se skutečně stalo.

Trochu jako argument mezi tabulátory a mezerami, tento argument může a bude nějakou dobu fungovat. To znamená, že obě strany diskuse mají zásluhy a při standardizaci způsobu, jakým bude váš tým fungovat, je důležité zvážit to.

Aby cokoli z toho dávalo smysl, nejdříve si musíme promluvit o sloučení závazků v Gitu. Všechny revize Git mají identifikátory potvrzení - ty dlouhé hexadecimální řetězce - a jsou jedinečné. Jsou vyrobeny z informací o sadě změn, zprávě o potvrzení, autorovi, časovém razítku a nadřazeném potvrzení, na které byly použity.

To znamená, že pokud je stejné potvrzení použito na jiného rodiče, i když výsledný kód skončí identicky, nový potvrzení bude mít jiný identifikátor potvrzení. Sloučené závazky nemají jednoho, ale dva rodiče.

V protokolu vypadají takto:

spáchat 41ea02cc8a1d2964c4f7b46b5f6b11cc04327959 Sloučit: a8d1421 e71dbf5 Autor: Lorna Mitchell [email protected]> Datum: Po 22. prosince 19:48:34 2014 +0000 Sloučit větev ‚akrabat-update-homepage-s-open-cfps‘

Všimněte si zvláštního řádku ve zprávě o potvrzení, která začíná Sloučit: .... Dvě čísla jsou odkazy na potvrzení dvou rodičů pro toto potvrzení - jedno z každé z větví, které jsou sloučeny dohromady.

Rychlý posun vpřed

Sloučení však nemusí vždy vypadat takto. Pokud na větvi dojde ke změnám, ale ne například na hlavní větvi, dojde k ‚sloučení rychle vpřed '. Začneme touto situací: změny na větvi funkce, ale ne na hlavní (jak je znázorněno na obrázku 5). Pokud jen požádáme Git o sloučení této větve, bude to ‚rychle vpřed '.

Když dojde ke sloučení, není ve skutečnosti potřeba žádné sloučení. Závazky na větvi funkcí pokračují od nejnovějšího potvrzení na hlavní větvi a vytvářejí lineární historii. Git proto rychle vpřed, přesuňte hlavní štítek ke špičce větve prvku, abychom odtud mohli pokračovat (obrázek 6). Pokud míříte na tradičnější vzor sloučení, můžete to vynutit pomocí přepínače --no-ff. Tím se vytvoří historie, která vypadá jako obrázek 7.

Přepínač --no-ff řekne Gitu, aby se nepředával vpřed, ale aby vytvořil sloučení. Mnoho strategií větvení vyžaduje, aby byla tato technika použita při sloučení větví. Většinou budeme stejně potřebovat sloučení, protože došlo k změnám jak ve větvi funkcí, tak ve větvi, do které se slučujeme. V některých situacích - pro mě je to obvykle při vytváření větve opravy hotfix - může být užitečné vynutit slučovací potvrzení, aby byla historie jasná přesně na tom, do které větve byla sloučena.

Strategie větvení

Snad nejznámější rozvětvovací strategií je Git Flow, což je velmi komplexní strategie. Tak komplexní, ve skutečnosti potřebuje celou sadu skriptů, aby ji mohl správně používat! Podle mých zkušeností je Git Flow příliš mnoho pro všechny, ale velmi velké a technicky vyspělé týmy, které řeší problémy napříč více verzemi najednou.

Každá strategie větvení, kterou jsem kdy implementoval, však čerpala nápady z tohoto přístupu a v tomto článku jsem se je pokusil rozebrat.

Samotná strategie větvení je proces; Dokument. Je to místo, kde jako tým zachytíte svůj přístup a přístup ke způsobu, jakým produkujete, sledujete a dodáváte kód. Každý chápe, jak každá z pohyblivých částí procesu funguje (alespoň na úrovni kódu - sociální a politické problémy jsou tématem jiného článku) a jak spolupracovat na dosažení cíle, na který všichni směřujete. Strategie větvení může být jednoduchá jako stránka na wiki společnosti - něco, co dává strukturu způsobu vaší práce. Může to být také skvělé místo, kam dát Git cheatsheet, jak provádět různé kroky.

Zjistil jsem, že zavedení strategie větvení značně zlepšuje jak kvalitu práce, tak důvěru a komunikaci týmu. Věnujte trochu času dohodě a zaznamenejte svou strategii, a pak jděte a buďte ještě úžasnější, než jste byli dříve.

Slova: Lorna Mitchell

Lorna Mitchell je autorka, trenérka a vývojářka se specializací na PHP, API a Git. Další pomoc od ní získáte přečtením jejího sešitu Git, který obsahuje praktická cvičení pro zdokonalení vašich dovedností. Tento článek byl původně publikován v čísle 267 čistého časopisu.

Líbilo se vám to? Přečtěte si tyto!