GitHub Flow

Problémy s git-flow

Všude jezdím a učím lidi o systému Git a téměř na každé přednášce a semináři, které jsem v poslední době absolvoval, se mě ptali, co si myslím o git-flow. Vždy odpovídám, že si myslím, že je skvělý – vzal systém (Git), který má milion možných pracovních postupů, a zdokumentoval dobře otestovaný, flexibilní pracovní postup, který funguje pro spoustu vývojářů poměrně jednoduchým způsobem. Stal se jakýmsi standardem, takže vývojáři mohou přecházet mezi projekty nebo společnostmi a tento standardizovaný pracovní postup znají.

Má však své problémy. Slyšel jsem řadu názorů od lidí v tom smyslu, že se jim nelíbí, že se nové větve funkcí spouštějí z develop, a ne z master, nebo způsob, jakým se zpracovávají hotfixy, ale to jsou poměrně drobnosti.

Jedním z větších problémů pro mě je, že je to složitější, než si myslím, že většina vývojářů a vývojových týmů skutečně potřebuje. Je to natolik komplikované, že byl vyvinut velký pomocný skript, který má pomoci prosadit tok. To je sice super, ale problém je v tom, že ho nelze prosadit v grafickém uživatelském rozhraní Git, pouze v příkazovém řádku, takže jediní lidé, kteří se musí složitý pracovní postup opravdu dobře naučit, protože musí všechny kroky dělat ručně, jsou ti samí lidé, kteří se se systémem nesžijí natolik, aby ho mohli používat z příkazového řádku. To může být obrovský problém.

Oba tyto problémy lze snadno vyřešit pouhým mnohem jednodušším postupem. Ve službě GitHub nepoužíváme systém git-flow. Používáme a vždy jsme používali mnohem jednodušší pracovní postup Git.

Jeho jednoduchost mu dává řadu výhod. Jednou z nich je, že je pro lidi snadno pochopitelný, což znamená, že si ho rychle osvojí a málokdy, pokud vůbec, ho pokazí nebo musí vracet kroky, které udělali špatně. Další je, že nepotřebujeme obalový skript, který by nám ho pomohl prosadit nebo sledovat, takže používání grafických uživatelských rozhraní a podobně není problém.

GitHub Flow

Proč tedy na GitHubu nepoužíváme git-flow? No, hlavní problém je v tom, že neustále nasazujeme. Proces git-flow je navržen převážně kolem „vydání“. Ve skutečnosti nemáme „vydání“, protože nasazujeme do produkce každý den – často několikrát denně. Můžeme tak činit prostřednictvím našeho robota v chatovací místnosti, což je stejné místo, kde se zobrazují naše výsledky CI. Snažíme se proces testování a odesílání co nejvíce zjednodušit, aby se při něm každý zaměstnanec cítil pohodlně.

Tak pravidelné nasazování má řadu výhod. Pokud nasazujete každých několik hodin, je téměř nemožné zavést velké množství velkých chyb. Drobné problémy lze zavést, ale pak je lze velmi rychle opravit a znovu nasadit. Normálně byste museli udělat „hotfix“ nebo něco mimo běžný proces, ale je to prostě součást našeho běžného procesu – v toku GitHubu není žádný rozdíl mezi hotfixem a velmi malou funkcí.

Další výhodou neustálého nasazování je možnost rychle řešit problémy všeho druhu. Můžeme neuvěřitelně rychle reagovat na bezpečnostní problémy, na které jsme upozorněni, nebo implementovat malé, ale zajímavé požadavky na funkce, a přitom můžeme pro řešení těchto změn používat úplně stejný proces jako pro řešení běžného nebo dokonce rozsáhlého vývoje funkcí. Je to všechno stejný proces a je to velmi jednoduché.

Jak to děláme

Takže, co je GitHub Flow?

• Cokoli ve větvi master je nasaditelné
• Chcete-li pracovat na něčem novém, vytvořte z větve master větev s popisným názvem (tj: new-oauth2-scopes)
• Odesílejte do této větve lokálně a pravidelně odesílejte svou práci do stejně pojmenované větve na serveru
• Když potřebujete zpětnou vazbu nebo pomoc nebo si myslíte, že je větev připravena ke sloučení, otevřete požadavek na stažení
• Poté, co funkci zkontroluje a podepíše někdo jiný, můžete ji sloučit do větve master
• Jakmile je sloučena a posunuta do větve ‚master‘, můžete a měli byste ji okamžitě nasadit

To je celý průběh. Je to velmi jednoduché, velmi efektivní a funguje to pro poměrně velké týmy – GitHub má nyní 35 zaměstnanců, z nichž možná 15-20 pracuje na stejném projektu (github.com) současně. Myslím, že většina vývojových týmů – skupin, které pracují na stejném logickém kódu ve stejnou dobu, což by mohlo vést ke konfliktům – je přibližně této velikosti nebo menší. Zejména ty, které jsou dostatečně progresivní na to, aby prováděly rychlé a důsledné nasazení.

Podívejme se tedy na každý z těchto kroků postupně.

#1 – cokoli v hlavní větvi je nasaditelné

To je v podstatě jediné tvrdé pravidlo systému. Existuje pouze jedna větev, která má nějaký konkrétní a konzistentní význam, a tu jsme pojmenovali master. Pro nás to znamená, že byla nasazena nebo v nejhorším případě bude nasazena během několika hodin. Neuvěřitelně zřídka se stává, že se přetočí (větev se přesune zpět na starší revizi, aby se vrátila práce) – pokud se vyskytne nějaký problém, revize se vrátí nebo se zavedou nové revize, které problém opraví, ale větev samotná se téměř nikdy nevrací zpět.

Větev master je stabilní a vždy, vždy je bezpečné z ní nasazovat nebo z ní vytvářet nové větve. Pokud do větve master posunete něco, co není otestované nebo co rozbije sestavení, porušíte společenskou smlouvu vývojového týmu a obvykle z toho máte dost špatný pocit. Na každé větvi, kterou posíláme, jsou spuštěny testy a nahlášeny do chatu, takže pokud jste je nespustili lokálně, můžete jednoduše poslat do tematické větve (dokonce i větve s jedinou revizí) na serveru a počkat, až vám Jenkins řekne, jestli vše prošlo.

Mohli byste mít větev deployed, která se aktualizuje pouze při nasazení, ale to neděláme. Prostě vystavíme aktuálně nasazenou SHA přes samotnou webovou aplikaci a curl pokud potřebujeme provést porovnání.

#2 – vytvořte popisné větve mimo větev master

Když chcete na něčem začít pracovat, vytvoříte popisně pojmenovanou větev mimo stabilní větev master. Některé příklady v databázi GitHub jsou právě teď user-content-cache-key, submodules-init-task nebo redis2-transition. To má několik výhod – jednou z nich je, že při načítání vidíte témata, na kterých pracovali všichni ostatní. Další je, že pokud nějakou větev na chvíli opustíte a později se k ní vrátíte, poměrně snadno si vzpomenete, co to bylo.

To je příjemné, protože když přejdeme na stránku se seznamem větví GitHubu, můžeme snadno vidět, na jakých větvích se v poslední době pracovalo a kolik práce na nich zhruba je.

Je to skoro jako seznam připravovaných funkcí s aktuálním hrubým stavem. Tato stránka je úžasná, pokud ji nepoužíváte – zobrazuje pouze větve, na kterých se pracuje jedinečně vzhledem k aktuálně vybrané větvi, a řadí je tak, že ty, na kterých se pracovalo naposledy, jsou nahoře. Pokud budu opravdu zvědavý, mohu kliknout na tlačítko „Porovnat“ a podívat se, jaký je skutečný sjednocený seznam rozdílů a revizí, který je jedinečný pro danou větev.

Takže v době psaní tohoto článku máme v našem repozitáři 44 větví, na kterých se nepracuje, ale také vidím, že jen asi 9 nebo 10 z nich bylo v posledním týdnu odsunuto.

#3 – push do pojmenovaných větví neustále

Dalším velkým rozdílem oproti git-flow je, že push do pojmenovaných větví na serveru provádíme neustále. Protože jediná věc, o kterou se z hlediska nasazení musíme opravdu starat, je master, tlačení na server nikoho neplete a nemate – na všem, co není master, se prostě pracuje.

To také zajišťuje, že naše práce je vždy zálohovaná pro případ ztráty notebooku nebo selhání pevného disku. A co je ještě důležitější, umožňuje všem neustálou komunikaci. Jednoduché „git fetch“ vám v podstatě poskytne seznam TODO, na čem každý zrovna pracuje.

$ git fetchremote: Counting objects: 3032, done.remote: Compressing objects: 100% (947/947), done.remote: Total 2672 (delta 1993), reused 2328 (delta 1689)Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.Resolving deltas: 100% (1993/1993), completed with 213 local objects.From github.com:github/github * charlock-linguist -> origin/charlock-linguist * enterprise-non-config -> origin/enterprise-non-config * fi-signup -> origin/fi-signup 2647a42..4d6d2c2 git-http-server -> origin/git-http-server * knyle-style-commits -> origin/knyle-style-commits 157d2b0..d33e00d master -> origin/master * menu-behavior-act-i -> origin/menu-behavior-act-i ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config * svg-tests -> origin/svg-tests 87bb870..9da23f3 view-modes -> origin/view-modes * wild-renaming -> origin/wild-renaming

Každému také umožňuje podívat se na stránku GitHub Branch List, na čem ostatní pracují, takže si je může prohlédnout a zjistit, jestli nechce s něčím pomoci.

#4 – kdykoli otevřete pull request

GitHub má úžasný systém kontroly kódu zvaný Pull Requests, o kterém, obávám se, neví dost lidí. Mnoho lidí ho používá pro práci s otevřeným zdrojovým kódem – forkne projekt, aktualizuje projekt, pošle správci pull request. Lze jej však také snadno použít jako interní systém pro revizi kódu, což je to, co děláme my.

Vlastně jej používáme spíše jako zobrazení konverzace o větvích než jako pull request. V systému GitHub můžete posílat žádosti o stažení z jedné větve do druhé v rámci jednoho projektu (veřejného nebo soukromého), takže je můžete použít kromě „Prosím, sloučte to sem“ také k vyjádření „Potřebuji s tím pomoct nebo to zkontrolovat“.

Tady vidíte, jak Josh poslal Brianovi cc k přezkoumání a Brian přišel s radou k jednomu z řádků kódu. Dále můžeme vidět, jak Josh uznává Brianovy obavy a posouvá další kód, aby je vyřešil.

Nakonec můžete vidět, že jsme stále ve zkušební fázi – toto ještě není větev připravená k nasazení, používáme žádosti o stažení k přezkoumání kódu dlouho předtím, než ho chceme skutečně sloučit do master k nasazení.

Pokud jste se zasekli ve vývoji své funkce nebo větve a potřebujete pomoc nebo radu, nebo pokud jste vývojář a potřebujete, aby designér zkontroloval vaši práci (nebo naopak), nebo dokonce pokud máte jen málo kódu nebo žádný, ale nějaké kompakty screenshotů nebo obecné nápady, otevřete žádost o stažení. V systému GitHub můžete lidi ccovat přidáním @username, takže pokud chcete recenzi nebo zpětnou vazbu od konkrétních lidí, jednoduše je ccnete ve zprávě PR (jak jste viděli Joshe výše).

To je skvělé, protože funkce Pull Request umožňuje komentovat jednotlivé řádky ve sjednoceném diffu, jednotlivé revize nebo samotný pull request a stahuje vše inline do jednoho zobrazení konverzace.Umožňuje také pokračovat v odesílání do větve, takže pokud někdo komentuje, že jste něco zapomněli udělat, nebo je v kódu chyba, můžete ji opravit a odeslat do větve, GitHub zobrazí nové revize v zobrazení konverzace a vy můžete takto pokračovat v iteraci větve.

Pokud je větev otevřená příliš dlouho a máte pocit, že se vymyká synchronizaci s hlavní větví, můžete sloučit hlavní větev do své tematické větve a pokračovat. V diskusi k žádosti o tah nebo v seznamu revizí snadno zjistíte, kdy byla větev naposledy aktualizována s větví „master“.

Když je ve větvi opravdu a skutečně vše hotovo a máte pocit, že je připravena k nasazení, můžete přejít k dalšímu kroku.

#5 – sloučení až po přezkoumání žádosti o stažení

Neprovádíme jednoduše práci přímo na master nebo práci na tematické větvi a sloučíme ji, když si myslíme, že je hotová – snažíme se získat souhlas někoho dalšího ve firmě. Obvykle je to +1 nebo emoji nebo komentář „„, ale snažíme se, aby se na to podíval někdo jiný.

Jakmile to získáme a větev projde CI, můžeme ji sloučit do masteru k nasazení, čímž se automaticky uzavře žádost o vytažení, když ji odešleme.

#6 – nasazení ihned po revizi

Nakonec je vaše práce hotová a sloučená do větve master. To znamená, že i když ji nyní nenasadíte, lidé z ní budou vycházet při nové práci a při dalším nasazení, ke kterému pravděpodobně dojde za několik hodin, ji vytlačí. Protože tedy opravdu nechcete, aby někdo jiný tlačil něco, co jste napsali a co něco rozbije, lidé mají tendenci se ujistit, že je to opravdu stabilní, když je to sloučeno, a lidé mají také tendenci tlačit své vlastní změny.

Náš bot campfire, hubot, může provádět nasazení pro kteréhokoli ze zaměstnanců, takže jednoduchý:

hubot depoy github to production

bude nasazovat kód a zero-downtime restartovat všechny potřebné procesy. O tom, jak je to běžné, se můžete přesvědčit na GitHubu:

Vidíte, že 6 různých lidí (včetně člověka z podpory a designéra) deployovalo asi 24krát během jednoho dne.

Dělal jsem to pro větve s jednou revizí obsahující jednořádkovou změnu. Proces je jednoduchý, přímočarý, škálovatelný a výkonný. Můžete to udělat s feature větvemi s 50 revizemi, které na nich trvaly 2 týdny, nebo s 1 revizí, která trvala 10 minut. Je to tak jednoduchý a nenáročný proces, že vás neštve, že ho musíte provést i pro 1 revizi, což znamená, že se lidé málokdy snaží proces přeskočit nebo obejít, pokud není změna tak malá nebo bezvýznamná, že na tom prostě nezáleží.

Je to neuvěřitelně jednoduchý a výkonný proces. Myslím, že většina lidí bude souhlasit s tím, že GitHub má velmi stabilní platformu, že problémy jsou řešeny rychle, pokud se vůbec objeví, a že nové funkce jsou zaváděny rychlým tempem. Nedochází k žádným kompromisům v kvalitě nebo stabilitě, abychom získali větší rychlost nebo jednoduchost nebo méně procesů.

Závěr

Systém Git je sám o sobě poměrně složitý na pochopení, dělat pracovní postup, který s ním používáte, složitější, než je nutné, je prostě přidávání další mentální režie do dne každého z nás. Vždy bych se přimlouval za to, abyste používali co nejjednodušší systém, který bude vašemu týmu vyhovovat, a to tak dlouho, dokud nebude fungovat, a pak přidávali složitost jen v případě, že to bude nezbytně nutné.

Pro týmy, které musí dělat formální vydání v delším časovém intervalu (několik týdnů až několik měsíců mezi vydáními) a být schopny provádět hot-fixes a údržbové větve a další věci, které vyplývají z tak řídkého odesílání, má git-flow smysl a jeho použití bych velmi obhajoval.

Pro týmy, které mají nastavenou kulturu odesílání, které odesílají do produkce každý den, které neustále testují a nasazují, bych obhajoval výběr něčeho jednoduššího, jako je GitHub Flow.