Přijetí strategie větvení Gitu

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Distribuované systémy správy verzí, jako je Git, poskytují flexibilitu při používání správy verzí ke sdílení a správě kódu. Váš tým by měl najít rovnováhu mezi touto flexibilitou a potřebou konzistentní spolupráce a sdílení kódu.

Členové týmu publikují, sdílejí, kontrolují a iterují změny kódu prostřednictvím větví Gitu sdílených s ostatními. Přijměte strategii větvení pro váš tým. Můžete lépe spolupracovat a strávit méně času správou verzí a více času vývojem kódu.

Následující strategie větvení jsou založené na tom, jak git používáme tady v Microsoftu. Další informace najdete v tématu Jak používáme Git v Microsoftu.

Jednoduchá strategie vaší větve

Udržujte strategii větve jednoduchou. Vytvořte strategii z těchto tří konceptů:

  • Větve funkcí používejte pro všechny nové funkce a opravy chyb.
  • Sloučí větve funkcí do hlavní větve pomocí žádostí o přijetí změn.
  • Udržujte si vysoce kvalitní a aktuální hlavní větev.

Strategie, která tyto koncepty rozšiřuje a vyhýbá se rozporům, způsobí, že pracovní postup správy verzí pro váš tým bude konzistentní a snadno sledovatelný.

Použití větví funkcí pro vaši práci

Vyvíjejte funkce a opravujte chyby ve větvích funkcí založených na vaší hlavní větvi. Tyto větve se také označují jako větve témat. Větve funkcí izolují probíhající práci od dokončené práce v hlavní větvi. Vytváření a údržba větví Gitu je levná. I malé opravy a změny by měly mít vlastní větev funkcí.

Obrázek základního pracovního postupu větvení

Vytváření větví funkcí pro všechny vaše změny usnadňuje prohlížení historie. Podívejte se na potvrzení provedená ve větvi a podívejte se na žádost o přijetí změn, která větev sloučila.

Pojmenování větví funkcí podle konvence

Pomocí konzistentních zásad vytváření názvů pro větve funkcí identifikujte práci provedenou ve větvi. Do názvu větve můžete zahrnout i další informace, například kdo větev vytvořil.

Několik návrhů pro pojmenování větví funkcí:

  • users/username/description
  • users/username/workitem
  • oprava/popis chyby
  • feature/feature-name
  • feature/feature-area/feature-name
  • oprava hotfix/popis

Poznámka

Informace o nastavení zásad pro vynucení strategie pojmenování větví najdete v tématu Vyžadování složek větví.

Použití příznaků funkcí ke správě dlouhotrvajících větví

Přečtěte si další informace o používání příznaků funkcí v kódu.

Kontrola a sloučení kódu pomocí žádostí o přijetí změn

Kontrola, která se provádí v žádosti o přijetí změn, je zásadní pro zlepšení kvality kódu. Slučujte jenom větve prostřednictvím žádostí o přijetí změn, které projdou vaším procesem kontroly. Vyhněte se slučování větví do hlavní větve bez žádosti o přijetí změn.

Dokončení kontrol v žádostech o přijetí změn nějakou dobu trvá. Váš tým by se měl dohodnout na tom, co se od tvůrců a revidujících žádostí o přijetí změn očekává. Rozdělte odpovědnost za revidující, abyste mohli sdílet nápady napříč týmem a rozšířit znalosti o základu kódu.

Několik návrhů pro úspěšné žádosti o přijetí změn:

  • Dva revidující jsou optimálním číslem založeným na výzkumu.
  • Pokud už váš tým má proces kontroly kódu, přeneste žádosti o přijetí změn do toho, co už děláte.
  • Přiřazujte stejné revidující k velkému počtu žádostí o přijetí změn. Žádosti o přijetí změn fungují lépe, když se odpovědnost revidující sdílí napříč týmem.
  • V popisu uveďte dostatek podrobností, abyste revidující rychle zrychlili změny.
  • Do žádosti o přijetí změn zahrňte build nebo propojenou verzi změn spuštěných ve fázovaném prostředí. Ostatní můžou změny snadno otestovat.

Udržování vysoce kvalitní a aktuální hlavní větve

Kód ve vaší hlavní větvi by měl projít testy, měl by se sestavit čistě a vždy být aktuální. Vaše hlavní větev potřebuje tyto vlastnosti, aby větve funkcí vytvořené vaším týmem začínaly ze známé správné verze kódu.

Nastavte zásadu větve pro hlavní větev, která:

  • Vyžaduje žádost o přijetí změn ke sloučení kódu. Tento přístup zabraňuje přímému nasdílení změn do hlavní větve a zajišťuje diskuzi o navrhovaných změnách.
  • Automaticky přidá revidující při vytvoření žádosti o přijetí změn. Přidaní členové týmu zkontrolují kód a okomentují změny v žádosti o přijetí změn.
  • K dokončení žádosti o přijetí změn vyžaduje úspěšné sestavení. Kód sloučený do hlavní větve by se měl sestavit čistě.

Tip

Kanál sestavení pro vaše žádosti o přijetí změn by měl být rychle dokončený, aby nenarušoval proces kontroly.

Správa vydaných verzí

Větve vydaných verzí slouží ke koordinaci a stabilizaci změn ve vydané verzi kódu. Tato větev je dlouhodobá a na rozdíl od větví funkcí není sloučena zpět do hlavní větve v žádosti o přijetí změn. Vytvořte tolik větví verzí, kolik potřebujete. Mějte na paměti, že každá aktivní větev vydané verze představuje jinou verzi kódu, kterou potřebujete podporovat. Zamkněte větve vydaných verzí, když jste připraveni přestat podporovat určitou verzi.

Použití větví vydaných verzí

Vytvořte větev verze z hlavní větve, když se blížíte k vydání nebo jinému milníku, například ke konci sprintu. Dejte této větvi jasný název, který ji přidružuje k vydání, například release/20.

Vytvořte větve, které opraví chyby z větve vydané verze a sloučí je zpět do větve vydané verze v žádosti o přijetí změn.

Image of release branch workflows

Změna portu zpět do hlavní větve

Ujistěte se, že opravy jsou ve vaší i hlavní větvi vydané verze. Jedním z přístupů je provést opravy ve větvi release a pak přenést změny do hlavní větve, aby se zabránilo regresi v kódu. Dalším přístupem (a tím, který používá tým Azure DevOps) je vždy provádět změny v hlavní linii a pak je přenést do větve vydané verze. Můžete si přečíst další informace o naší strategii toku vydaných verzí .

V tomto tématu se budeme zabývat prováděním změn ve větvi vydané verze a jejich přenesením na hlavní řádek. Místo slučování používejte výběr třešniček, abyste měli přesnou kontrolu nad tím, která potvrzení se přesouvají zpět do hlavní větve. Sloučení větve vydané verze do hlavní větve může přinést změny specifické pro vydání, které v hlavní větvi nechcete.

Aktualizujte hlavní větev změnou provedenou ve větvi vydané verze pomocí těchto kroků:

  1. Vytvořte novou větev funkcí mimo hlavní větev, aby se změny převely.
  2. Vyberte si změny z větve vydané verze na novou větev funkcí.
  3. Ve druhé žádosti o přijetí změn sloučíte větev funkcí zpět do hlavní větve.

Aktualizované pracovní postupy větve vydané verze.

Tento pracovní postup větve verze udržuje pilíře základního pracovního postupu beze změny: větve funkcí, žádosti o přijetí změn a silnou hlavní větev, která má vždy nejnovější verzi kódu.

Proč pro vydané verze nepoužívat značky?

Jiné pracovní postupy větvení používají značky Gitu k označení konkrétního potvrzení jako verze. Značky jsou užitečné pro označení bodů v historii jako důležitých. Značky zavádějí do pracovního postupu další kroky, které nejsou nutné, pokud pro vydané verze používáte větve.

Značky se uchovávají a nasdílí odděleně od potvrzení. Členové týmu můžou snadno vynechat označení potvrzení a potom se musí vrátit k historii, aby značku opravili. Můžete také zapomenout na další krok pro nasdílení značky a nechat dalšího vývojáře pracovat ze starší verze kódu při podpoře vydané verze.

Strategie větve verze rozšiřuje základní pracovní postup větve funkcí pro zpracování vydaných verzí. Váš tým nemusí přijímat jiný nový proces správy verzí, než je výběr změn portů.

Správa nasazení

Můžete zpracovávat více nasazení kódu stejným způsobem, jakým zpracováváte více verzí. Vytvořte jasné zásady vytváření názvů, jako je nasazení/test výkonu, a zacházejte s větvemi prostředí jako s větvemi vydaných verzí. Váš tým by se měl dohodnout na procesu aktualizace větví nasazení pomocí kódu z hlavní větve. Opravy chyb pro výběr ve větvi nasazení zpět do hlavní větve. Použijte stejný postup jako přenesení změn z větve vydané verze.

Výjimkou z tohoto doporučení je, pokud používáte formu průběžného nasazování. Azure Pipelines můžete použít při práci s průběžným nasazováním k povýšení sestavení z hlavní větve na cíle nasazení.