Volba strategie toku kódu
Je důležité zvolit strategii toku kódu, která odpovídá způsobu, jakým váš tým funguje. Máte několik strategií, které je potřeba zvážit. Na konci modulu můžete prozkoumat možnosti. Webový tým Tailspin se rozhodne vytvořit strategii toku kódu, která je založená na Gitu a GitHubu.
Když Mara nastavovala Azure Boards, společně s týmem identifikovali několik počátečních úkolů, které je třeba vyřešit. Jedním z úkolů bylo vytvoření pracovního postupu založeného na Gitu.
Pojďme si poslechnout, jak se tým domlouvá na nalezení lepšího způsobu spolupráce. V současné době používají centralizovaný systém správy verzí, ale plán je přejít na Git, distribuovaný systém.
Mara pilně pracuje na svých přiřazených funkcích, když za ní přijde Andy.
Andy: Ahoj Mara. Na schůzce vedení se dnes ráno vyvolalo, že náš tým a tým pro vývoj her používají různé systémy správy verzí. Abychom zefektivnili sdílení prostředků mezi týmy, byli jsme požádáni o přechod na distribuovaný systém správy verzí, který dokáže lépe zvládnout spolupráci.
Mara: To je dobré vědět. Jestli si to pamatuješ, tak jsme to dali na naši desku. V současné době používáme centralizovaný systém správy verzí. Funguje to pro nás skvěle, ale souhlasím s tím, že distribuovaný systém správy verzí je lepší volbou, když začneme sdílet mezi týmy a náš tým se zvětší. Na našem panelu je také úkolem zvýšit viditelnost, aby všichni účastníci věděli, co dělají všichni. Myslím, že distribuovaný systém správy zdrojového kódu, jako je Git, by také pomohl.
Andy: Už nějakou dobu chci zkusit Git. Zdá se, že nemám čas. Je obtížné to nastavit a naučit se používat? Pokud se to dá zvládnout za rozumnou dobu, možná bychom s tím mohli začít pracovat. Už mě nebaví, jak musím pořád něco odkládat. A bylo by hezké vidět, co všichni dělají, a mít přístup k celému úložišti. V čem to tedy spočívá?
Mara: Dovolte mi to vysvětlit a pak se můžete rozhodnout, jestli to zní jako něco, co chceme implementovat hned.
Mara a Andy se přesunují k tabuli a diskutují o správě verzí.
Co je Git a distribuovaná správa verzí?
Mara: Kresba na levé straně je centralizovaná správa verzí, například to, co teď používáme. Máme centrální verzi základu kódu 
v Správa verzí Team Foundation (TFVC), kterou všichni používají. Každý pracuje na souborech, které potřebujeme změnit, a potom je sloučit zpět do hlavního úložiště, až s nimi skončíme.
Andy: Ano, a to pro nás pracuje. No, s výjimkou toho, kdy jsem byl zablokovaný čas, kdy se zásadní změna sloučila do centrálního úložiště.
Mara: Dobře! Byl jste zablokovaný 
. Potíže s takovým blokováním bychom mohli s TFVC vyřešit, kdybychom nastavili strategii větvení, ale v naší aktuální konfiguraci by slučování mohlo být o něco složitější. A když jsme měli tu zásadní změnu 
, nikdo nemohl udělat žádnou práci, dokud se to nevyřeší. Tento problém je vždy číhající, protože všichni používáme stejnou kopii kódu.
Na pravé straně je nákres distribuované správy verzí. Stále máme centrální úložiště 
, které je stabilní verzí základu kódu, ale každý vývojář má svou vlastní kopii 
, ze které má pracovat. To nám umožňuje experimentovat a vyzkoušet různé přístupy, aniž by to mělo vliv na centrální úložiště.
Distribuovaná správa verzí také zajišťuje, aby se do centrálního úložiště sloučil pouze pracovní kód 
. Mohli bychom ho dokonce nastavit tak, aby se kód nedá sloučit, dokud ho nezkontrolujeme.
O Azure DevOps je skvělé, že funguje dobře jak s centralizovanými systémy správy verzí, tak s distribuovanými systémy správy verzí.
Andy: Co se stane, když stejný soubor změní víc než jedna osoba?
Mara: Git může často sloučit více změn automaticky. Samozřejmě chceme mít vždy jistotu, že kombinace změn vede k tomu, že kód funguje. Pokud Git nedokáže sloučit změny automaticky, označí konflikty přímo v souborech, aby pak pověřený člověk mohl zvolit, které změny se mají přijmout.
Andy: V tuto chvíli je náš kód uložený na našem vlastním serveru. Pokud se přesuneme do správy distribuovaných verzí, kde se uloží kód?
Mara: Jsem rád, že ses zeptal. Tady přichází ke slovu hostování.
Kde můžu hostovat svoje úložiště?
Mara: Když se rozhodujeme, kde hostovat naše úložiště, máme několik možností. Můžeme je například hostovat na místním serveru, v Bitbucketu nebo na GitHubu. Bitbucket a GitHub jsou webová řešení pro hostování. Přístup k nim je možný odkudkoliv.
Andy: Použili jste některou z nich?
Mara: V minulosti jsem používal GitHub. Má funkce, které jsou pro vývojáře důležité, například snadný přístup ke změnám protokolů a funkcí správy verzí z příkazového řádku nebo online portálu.
Andy: Jak tedy Git funguje?
Jak se používá Git?
Mara: Jak jsem zmínil dříve, s distribuovanými systémy mají vývojáři volný přístup k libovolnému souboru, který potřebují, aniž by ovlivnili práci jiných vývojářů, protože mají vlastní kopii úložiště. Místní kopii úložiště se říká klon.
Když pracujeme na nějaké funkci nebo opravě chyby, obvykle chceme vyzkoušet různé přístupy, dokud nenajdeme nejlepší řešení. Vyzkoušení kódu ve vaší kopii hlavního základu kódu ale není dobrý nápad, protože možná nebudete chtít zachovat několik prvních pokusů.
Aby vám git dal lepší možnost, má funkci nazvanou větvení, kde můžete udržovat tolik kopií, kolik chcete, a sloučit zpátky jenom ten, který chcete zachovat. To udržuje hlavní větev ve stabilním stavu.
Andy: Zatím dostávám koncepty. A jak funguje vracení kódu se změnami?
Jak se místní změny dostanou do hlavního základu kódu?
Mara: V Gitu se obvykle nazývá mainvýchozí větev nebo kmen .
Až budete mít pocit, že je váš kód připravený ke sloučení do main větve v centrálním úložišti, které sdílí všichni vývojáři, vytvoříte to, co se nazývá žádost o přijetí změn. Když vytvoříte žádost o přijetí změn, řeknete ostatním vývojářům, že máte kód připravený ke kontrole a chcete, aby se sloučil do main větve. Když je vaše žádost o přijetí změn schválena a sloučena, stane se součástí centrálního základu kódu.
Jak vypadá pracovní postup větvení?
Krok 1: Když začnete pracovat na nové funkci nebo opravě chyb, první věc, kterou chcete udělat, je zajistit, že začínáte s nejnovější stabilní základ kódu. Za tím účelem můžeš synchronizovat svoji místní kopie větve main s kopií na serveru. Tím se přetáhne do místní kopie všechny ostatní změny vývojáře, které byly vloženy do main větve na serveru od poslední synchronizace.
Krok 2: Abyste měli jistotu, že pracujete jenom na kopii kódu, vytvoříte novou větev jenom pro tuto funkci nebo opravu chyb. Jak si můžete představit, mít mnoho větví pro všechny věci, které děláte, může být těžké si zapamatovat, takže použití dobré konvence pojmenování je důležité.
Před provedením změn v souboru si můžete rezervovat novou větev, abyste věděli, že pracujete na souborech z této větve, a ne z jiné větve. Větve můžeš kdykoliv přepínat tak, že si vezmeš potřebnou větev.
Krok 3: Teď můžete bezpečně provádět požadované změny, protože tyto změny jsou jenom ve vaší větvi. Při práci můžete potvrdit změny ve větvi, abyste měli jistotu, že nepřijdete o žádnou práci, a poskytnout způsob, jak vrátit všechny změny, které jste udělali v dřívějších verzích. Než potvrdíš změny, je třeba soubory rozfázovat, aby Git věděl, co chceš potvrdit.
Krok 4: Dalším krokem je nasdílení změn nebo nahrání místní větve do vzdáleného úložiště (například GitHub), aby ostatní viděli, na čem pracujete. Nedělej si starosti, tímto se ještě provedené změny nebudou slučovat. Změny ve své práci můžeš sdílet tak často, jak chceš. Ve skutečnosti je to dobrý způsob, jak zálohovat práci nebo umožnit práci z více počítačů.
Krok 5: Tento krok je běžný, ale nevyžaduje se. Až budete spokojeni s tím, že váš kód funguje podle vašich představ, můžete vzdálenou main větev stáhnout nebo sloučit zpět do místní main větve. Odehrály se v ní totiž změny, které tvoje místní větev main ještě neobsahuje. Po synchronizaci vzdálené main větve s vaší větví sloučíte místní main větev do pracovní větve a znovu otestujete sestavení.
Tento proces pomáhá zajistit, aby tvoje funkce fungovala s nejnovějším kódem. Také pomáhá zajistit, aby se tvoje práce hladce integrovala, když odešleš žádost o přijetí změn.
Krok 6: Váš místní kód se teď musí potvrdit a odeslat do hostovaného úložiště. Je to stejné jako v krocích 3 a 4.
Krok 7: Konečně jste připraveni navrhnout změny ve vzdálené main větvi. Uděláš to tak, že vytvoříš žádost o přijetí změn. Když je nakonfigurovaný v Azure Pipelines nebo jiném systému CI/CD, tento krok aktivuje proces sestavení a můžete sledovat, jak se změny procházejí kanálem. Jakmile sestavení proběhne úspěšně a ostatní schválí vaši žádost o přijetí změn, můžete kód sloučit do vzdálené main větve. (Je stále na člověku, aby změny sloučil.)
Andy: Tohle všechno vypadá složitě a těžko se učí.
Mara: Git se může zdát zastrašující, protože je tak silný, ale jakmile dostanete hang toku, začne se cítit přirozeně.
Denně budete používat jenom několik příkazů. Tady je souhrn:
| Kategorie | Úkol | Příkaz |
|---|---|---|
| Správa úložiště | Vytvoření úložiště Git | git init |
| Stažení vzdáleného úložiště | git clone |
|
| Pobočka | Vytvoření větve | git checkout |
| Rozfázování a potvrzení změn | Zobrazení souborů, které se změnily | git status |
| Rozfázování souborů k potvrzení | git add |
|
| Potvrzení souborů do větve | git commit |
|
| Vzdálená synchronizace | Stažení větve ze vzdáleného úložiště | git pull |
| Nahrání větve do vzdáleného úložiště | git push |
Andy: To zní jako skvělý výchozí bod. Toto určitě zvládnu. A pokročilejší příkazy se může naučit, až je budu potřebovat.