Jak používat větve Git ke strukturování vašeho programovacího projektu

Filmy a televizní programování zobrazují jako zběsilá aktivita Hollywood Hacks: Nejlepší a nejhorší hackování ve filmech Hollywood Hacks: Nejlepší a nejhorší hackování ve filmech Hollywood a hackerství nevycházejí. Zatímco hackování v reálném životě je obtížné, hackování filmů často zahrnuje jen bušení na klávesnici, protože vaše prsty zmizí z módy. . Časovač bomby se odpočítává a nerdy sidekick, který byl břemenem, až do té chvíle horečně pracuje na notebooku. Kód letí přes obrazovku, dokud uspokojivým stiskem nestiskne konečný návratový klíč klepat! Časovač se zastaví a vše je opět na světě. Ale programování není nic takového. Zahrnuje návrhové dokumenty, makety uživatelského rozhraní a recenze kódů. A více než cokoli jiného zahrnuje pokus a omyl, zejména pokud jste začátečník (jako já).

Nyní už můžete být přesvědčeni o tom, že je důležité udržet vaše kódovací projekty v řízení zdroje Co je Git a proč byste měli používat kontrolu verzí, pokud jste vývojář Co je Git a proč byste měli používat kontrolu verzí, pokud jste vývojář Jako weboví vývojáři hodně času máme tendenci pracovat na webech pro místní rozvoj, pak vše jednoduše nahrajeme, až budeme hotovi. To je v pořádku, když jste jen vy a změny jsou malé,…. Odevzdání všech těchto pokusů a omylů do úložiště způsobí velký a neuspořádaný projekt s mnoha revizemi. Většina odevzdaných závazků bude obsahovat věci, které jsou rozbité, tak proč je uložit? Kecy větev Tato funkce může pomoci zabránit tomu, aby byl tento chaotický kód daleko od věcí, o kterých víte, že fungují.

V tomto článku se podíváme na to, co znamená větvení vašeho kódu, jak to provést a jak spravovat aktualizace “hlavní” větev.

Vytvoření větve Git

Naučili jsme se od našeho úvodu do řízení zdrojů Správa verzí souborů jako programátor s Gitem Správa verzí souborů jako programátor s programem Git Programátoři vytvořili systémy pro správu verzí (VCS) k řešení problémů s řízením verzí souborů. Podívejme se na základy řízení verzí pomocí dnešního špičkového systému, Gite. že můžete vytvořit nové úložiště pomocí následujícího příkazu v terminálu:

git init

Když to uděláte, vytvoří skrytý adresář v aktuální cestě nazvaný “.git.” Pokud to nevidíte, prostudujte si některé z našich předchozích článků o prohlížení skrytých jednoduchých způsobů, jak zobrazit skryté soubory a složky ve Windows 10, 8.1 a 7 jednoduchých způsobů, jak zobrazit skryté soubory a složky ve Windows 10, 8.1 a 7 Potřebujete vidět skryté soubory a složky ve Windows? Zde je návod, jak je zobrazit ve Windows 10, 8.1 a 7, aby se před vámi nic nezakrývalo. soubory Skrýt a najít libovolný soubor v systému Mac OS X Skrýt a najít libovolný soubor v systému Mac OS X Neexistuje žádný přímý způsob, jak rychle skrýt nebo odhalit skryté soubory v systému Mac OS X tak, jak je to v systému Windows - ale je to možné. . Tento adresář obsahuje všechny informace potřebné k uchování historie revizí vašich souborů. Jakmile nastavíte správce souborů tak, aby zobrazoval skryté soubory, můžete otevřít složku .git a zobrazit řadu podadresářů. Jeden z nich se nazývá “refs” (na obrázku níže) a jeho “hlavy” podadresář obsahuje výpisy všech větví ve vašem projektu. Na začátku budete mít jen jeden, dabovaný “mistr.”

Adresář refs uchovává záznam o větvi, nikoli však o samotné větvi. Alespoň ne větev, kterou jste v současné době používá. Tyto soubory jsou uloženy v pracovním adresáři (“~ / Temp / postprograming-git-branch” ve výše uvedeném příkladu), abyste k nim měli přístup normálním způsobem. Přesně tak vytvoříme náš první soubor (pojmenovaný “first-file.txt”) v pracovním adresáři, tj. mimo adresář .git. Zaškrtněte to pomocí důvěryhodných příkazů z předchozího úvodního článku do článku git Správa verzí souborů jako programátor pomocí programu Git Správa verzí souborů jako programátor pomocí programu Git Programátoři vytvořili systémy pro správu verzí (VCS) k řešení problémů s kontrolou verzí souborů. Podívejme se na základy řízení verzí pomocí dnešního špičkového systému, Gite. :

Nyní vidíme, že pracovní adresář obsahuje dva soubory, jeden, který jsme se zavázali, a jeden vytvořený automaticky pomocí git (obsahuje zprávu o potvrzení, kterou jsme právě zadali).

Nyní vytvořme novou větev git s názvem “testování”:

git větve testování

Kontrola pobočky a práce v ní

Můžeme vydat výše uvedený příkaz bez jakýchkoli jmen, abychom získali seznam všech větví a také těch, které právě používáme (tj. Která je “odhlásil”):

Nyní, když prozkoumáme strukturu adresářů, uvidíme “.git / refs / heads” nyní má dva soubory, každý pro jeden “mistr” a “testování.”

Každý z nich je seznam závazků, které tvoří větev. Pokud například prozkoumáme “mistr” větev s “git log” příkaz, můžeme vidět řádek pro každý z potvrzených závazků v dané větvi.

Proces “odhlášení” větev znamená, že změny provedené v souborech budou součástí této větve, ale nikoli jiných větví. Předpokládejme například, že se podíváme na testovací větev git pomocí následujícího příkazu:

git checkout testování

Pak přidáme řádek textu do souboru first-file.txt, který se samozřejmě zavazuje poté. Pokud přepnete zpět na hlavní větev, zjistíte, že soubor je stále prázdný ( kočka příkaz zobrazí obsah souboru v terminálu):

Ale vrátit se k “testování” větev, soubor stále obsahuje přidaný text:

Ale vše, co jsme kdy viděli v samotném adresáři, je jediný soubor “first-file.txt.” Kde tedy jsou tyto dvě alternativní verze stejného souboru? Adresář .git odpovídá za tyto změny, ale ne způsobem, který byste mohli očekávat.

Jak Git ukládá věci

Pokud byste měli prozkoumat úložiště pro jiné systémy pro správu verzí, jako je Subversion, zjistili byste, že udržují jednu kopii na revizi pro každý jednotlivý soubor. To znamená, že pokud máte úložiště jednoho souboru, pak vytvoříte dvě větve, repo obsahuje dvě různé kopie tohoto souboru. Ve skutečnosti to skutečně používáte “svn copy” jako příkaz k vytvoření pobočky v Subversion! Na druhé straně git pracuje na konceptu “Změny.”

Výstup výše nám říká celý obsah “kufr” (SVN verze “mistr”) byla zkopírována. Pohled ve správci souborů toto potvrzuje:

“.git / objects” adresář je to, co drží všechny tyto malé změny, a každá z nich je sledována pomocí ID. Například na obrázku níže uvidíte soubory s dlouhými názvy ve stylu ID. Každý žije ve složce pojmenované se dvěma hexadecimálními znaky (8c a 8d níže).

Tyto názvy složek a souborů společně vytvářejí ID pro konkrétní změnu (ve skutečnosti hash SHA1). Jejich obsah můžete prozkoumat pomocí git cat-file příkaz. Na základě jejich upravených dat můžeme vidět jeden začátek “8d” přišel první a nic neukazuje. Zatímco jeden začíná “8c” obsahuje řádek textu, který jsme přidali do souboru v “testování” větev.

S sebou je to git větve (včetně výchozího) “mistr”) nejsou oddělené “složky” obsahující kopie souborů. Jsou to spíše seznamy změn provedených v souborech v průběhu času. Toto je efektivnější úložiště, ale výsledek je stejný. Cokoli, co děláte (rozbijete?) V git větvi, zůstane tam, dokud jej nespojíte.

Strategie pro sloučení zpět do hlavní větve (Chcete-li smazat nebo ne smazat?)

Předpokládejme, že jste měli existující projekt s množstvím souborů, do kterých jste poté rozvětvili “testování,” a udělali na tom nějakou práci. Nyní chcete tyto změny vrátit zpět do “mistr” větev. Můžete dělat s následujícím z “mistr” větev:

git sloučení testování

Pokud nedochází ke konfliktům, změna sestávající z nového textu bude aplikovaný na “mistr.” Výsledek je “first-file.txt” budou v obou větvích stejné. Přesto tam nikdy nebyli nikdy alternativní verze souboru.

Nyní přichází otázka, co dělat s pobočkou? Pro jednání s pobočkami existují dvě společné strategie.

1. Jedním z nich je udržet git větev jako “testování” hrát kolem (viz výše). Vyzkoušíte některé věci a pokud je můžete přimět k práci, sloučte změny zpět do “mistr.” Pak můžete ukončit práci na této větvi nebo ji úplně zbavit. To znamená, že “mistr” je nejstabilnější verze kódu, protože by měl obsahovat pouze věci, o kterých víte, že fungují. Tento přístup si můžete také představit jako použití “hlavní větve.” Je to proto, že jejich účelem je upřesnění jednoho (nebo několika) konkrétních dodatků do kódu.
2. Jiným přístupem je dělat všechny své hlavní práce na internetu “mistr” větev, dělat cesty podél cesty. Až budete s touto funkcí spokojeni, vytvoříte v ní větev, kterou opravíte a podobně. Výsledkem je více a “větev uvolnění” (viz níže), protože končí uvolněním. To také znamená vaše “mistr” větev je obvykle nejstabilnější verze vašeho kódu.

Použijte kteroukoli metodu, která je pro vás nejlepší

První přístup je běžnější při práci s git. Jeho další funkce (konkrétně značky) usnadňují označení konkrétního snímku kódu jako “stabilní.” Také se hodí lépe pro větší, kolaborativní projekty. Při práci na vlastních osobních projektech však můžete použít kterýkoli z nich pro vás nejvhodnější. Skvělá věc při používání gitu je, že zachytíte všechny své změny, takže se můžete vždy vrátit a něco najít. A uspořádání vašeho projektu pomocí větví git to dělá trochu snazší.

Jak přistupujete k pobočkám ve svých projektech? Používáte je k experimentování a poté je do koše? Nebo představují podrobnou historii vaší práce na projektu?

Pokud máte nějaké chytré způsoby, jak jednat s pobočkami ve svých git projektech, dejte nám vědět níže!