Pokud budete psát software pro život v roce 2018, pak mohu s jistotou říci, že jste s Gitem obeznámeni. nástroj vytvořený Linusem Torvaldsem se stal synonymem pro správu verzí. A bezpochyby je jednou z nejlepších vlastností Gitu to, jak to odstraňuje bolest větvení a slučování. Existuje několik způsobů, jak vytvořit větev v Gitu. V tomto příspěvku některé z nich zkontrolujeme. Potom skončíme malou reflexí modelu větvení a větvení Gitu obecně.

Vytvoření větve z mistra

Větve v Gitu vytváříte nepřekvapivě pomocí příkazu branch. Stejně jako mnoho jiných příkazů Git je i „branch“ velmi výkonný a flexibilní. Kromě vytváření větví je lze použít i k jejich výpisu a mazání a můžete je dále přizpůsobovat příkaz pomocí širokého seznamu parametrů. Začneme prvním způsobem vytvoření větve. Řekněme, že chcete vytvořit novou složku s názvem „moje aplikace“, zadejte ji a spusťte nové úložiště Git. Přesně tak to uděláte:

mkdir my-appcd my-appgit init

Nyní máte nové, prázdné úložiště Git. Prázdná úložiště jsou ale nudná. A co vytvoření nového souboru markdown s napsaným „Hello World!“?

echo Hello World! > file.md

Pokud spustíte „stav git“, měla by se zobrazit zpráva, že váš soubor není sledován:

Nesledované soubory jsou také nevychladlé, takže je sledujte:

git add file.md

A nakonec si vytvořme první potvrzení:

git commit -m "First commit"

Nyní máme úložiště s jednou větví, které má právě jeden potvrzení. To nemusí znít jako nejvíce vzrušující věc na světě (protože to opravdu není), ale je to určitě méně nudné než mít repo bez jakýchkoli závazků, že? Nyní řekněme, že z jakéhokoli důvodu musíte soubor změnit „Obsah. Ale ty to neděláš cítit se jako to dělat. Co když se něco pokazí a vy nějak zkazíte krásný nedotčený obsah souboru? (Ano, vím, že je to jen nějaký hloupý soubor, ve kterém je „Hello World!“, Ale využijte úžasných schopností své fantazie a myslete na tento soubor jako na zástupce mnohem složitějšího projektu.) Řešení tohoto dilematu je samozřejmě vytváření nové větve:

git branch exp

Takže nyní máme novou větev nazvanou „exp“ pro experimentování Někteří lidé, kteří jsou zvyklí používat různé systémy správy verzí, zejména centralizované, by mohli říci, že větve mají stejný „obsah“. To však není úplně přesné, když mluvíme o Gitu. Přemýšlejte o větvích jako o odkazech, které odkazují na daný závazek.

Vytvoření větve ze závazku

Předpokládejme, že z jakéhokoli důvodu se vzdáme našeho experimentu, aniž bychom přidali jediný zavázat se k nové větvi. Pojďme se vrátit k hlavnímu a smazat větev exp:

git checkout mastergit branch -d exp

Teď, když jsme zpět v jedné větvi, Pojďme k tomu přidat nějaké závazky, abychom simulovali prováděnou práci:

Představte si, že po provedení všech těchto „prací“ se naučíte, že z jakéhokoli důvodu se musíte vrátit v čase, kdy byly v souboru pouze dva řádky a od té doby vytvářely nové změny. Zároveň však musíte zachovat pokrok, který jste již udělali. Jinými slovy, chcete vytvořit větev z minulého potvrzení. Jak byste to udělali ? V Gitu má každý potvrzení jedinečný identifikátor. Můžete to tedy snadno zjistit pomocí příkazu „git log“. Chcete-li vytvořit novou větev založenou na konkrétním potvrzení, stačí předat její hash jako parametr příkazu větve:

git branch new-branch 7e4decb

Mimochodem, většinu času nepotřebujete ani celý hash. Udělá to jen prvních pět nebo šest znaků.

Vytvoření větve ze značky

Pokud jste s Gitem trochu zkušenější, měli byste být obeznámeni s koncept značek. Značky používáte k označení, že dané potvrzení je nějakým způsobem důležité nebo speciální. Například značky se obvykle používají k označení skutečných verzí produktu. Pokud ve své aplikaci nějakou dobu pracujete a věříte, že je čas vydat verzi 1.0, co obvykle uděláte, je narazit na čísla verzí, kdykoli je to nutné, provést tyto změny a poté přidat značku do daného konkrétního bodu v čase. Chcete-li vytvořit značku, obvykle spustíte něco podobného:

git tag -a v1.0 -m "First major version"

Parametr „-a“ označuje, že se jedná být anotovanou značkou. Na rozdíl od odlehčené značky se jedná o plnohodnotný objekt Git, který obsahuje informace, jako je jméno a e-mail odesílatele, časové razítko a zpráva. Nyní máte značku, což znamená, že tento konkrétní bod v historii je zvláštní a má název. Pěkný. Jako obvykle můžete pokračovat v práci a vytvářet a provádět změny, které budou součástí verze 1.1. Dokud se neobjeví hlášení o chybě. Někteří klienti, kteří byli aktualizováni na 1.Verze 0 produktu říká, že funkce importu nefunguje tak, jak bylo zamýšleno. No, teoreticky byste mohli opravit chybu v hlavní větvi a nasadit ji. Ale pak by klienti obdrželi funkce, které jsou potenciálně nevyzkoušené a neúplné. -Ne. Takže, co děláš? Odpověď: Vytvoříte novou větev ze značky, kterou jste vytvořili, abyste označili hlavní verzi. Vyřešíte problém tam, sestavíte a nasadíte. A pravděpodobně byste to měli později sloučit, abyste ho později zvládli, takže další vydání obsahují opravu . Jak byste na to šli? Snadné:

git branch <NAME-OF-THE-BRANCH> <TAG>

Konkrétněji na našem předchozím příkladu:

git branch fix-bug-123 v1.0

Poté si můžete novou pobočku vyzkoušet jako obvykle. Nebo ještě lépe, vše zvládnete v jednom kroku:

git checkout -b fix-bug-1234 v1.0

Vytvoření pobočky ve stavu odpojené hlavy

Přáli jste si někdy vrátit se v čase? S Gitem to je možné … alespoň pokud jde o soubory v našem úložišti. Kdykoli můžete zkontrolovat potvrzení, pokud znáte jeho hash:

git checkout <SHA1>

Po spuštění vám Git zobrazí zvědavou zprávu:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Když se odhlásíte potvrzení, vstoupíte do zvláštního stavu c Alled, jak vidíte, „oddělená HLAVA“. I když můžete v tomto stavu provádět změny, tyto závazky nepatří do žádné pobočky a stanou se nepřístupnými, jakmile si prohlédnete jinou větev. Ale co když si chcete tyto závazky ponechat? Odpovědí, není překvapením, je použít znovu příkaz „checkout“ pro vytvoření nové větve:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

A samozřejmě už víte, že můžete napsat poslední dva řádky jako jediný příkaz:

git checkout -b new-branch-to-keep-commits

Docela snadné, že?

Jen proto, že můžete … Neznamená to, že byste měli

Gitův rozvětvovací model je jedním z jeho prodejních míst. Z toho, co je v jiných systémech řízení zdrojů, je bolestivý a dokonce pomalý proces, udělá hračka. že Git úspěšně demokratizoval větvení pro masy. Existuje však vážné nebezpečí. Kvůli lacinosti větvení v Gitu by se někteří vývojáři mohli dostat do pasti práce s větvemi s extrémně dlouhou životností nebo s využitím pracovních toků nebo větvících modelů, které zpozdí inte strouhání. My jako průmysl jsme tam byli. „Udělali jsme to. To nefunguje. Místo toho přijměte pracovní postupy, které využívají extrémně krátkodobé větve. Budete mít zabezpečené pískoviště, ve kterém můžete kódovat, aniž byste se báli rozbití věcí nebo plýtvání časem svých spolupracovníků. Ale ptáte se: „Jak nasadím kód s částečně dokončenými funkcemi?“ V takovém případě jde o příznaky záchrany. Větve Git jsou mocným nástrojem. Používejte je moudře a nezneužívejte je. A když „nestačí“, využijte nepřetržité doručování / nepřetržitou integraci spolu s příznaky funkcí – včetně specializovaných nástrojů, které máte k dispozici – aby se vaše aplikace mohly dostat na další úroveň.