Přijetí strategie větvení Gitu

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

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 nutností spolupracovat a sdílet kód konzistentním způsobem.

Č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 spolupracovat lépe a trávit méně času správou správy verzí a více času vývojem kódu.

Následující strategie větvení jsou založené na způsobu, jakým zde používáme Git v Microsoftu. Další informace najdete v tématu Jak používáme Git v Microsoftu.

Udržujte strategii větve jednoduchou

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čení větví funkcí do hlavní větve pomocí žádostí o přijetí změn
• Udržujte vysoce kvalitní a aktuální hlavní větev.

Strategie, která tyto koncepty rozšiřuje a zabraňuje rozporům, bude mít za následek pracovní postup správy verzí pro váš tým, který je 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 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. Větve Gitu jsou levné pro vytváření a údržbu. I malé opravy a změny by měly mít vlastní větev funkcí.

Vytváření větví funkcí pro všechny 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 také zahrnout 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 chyby nebo popis
• 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í naleznete v tématu Vyžadovat složky 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á probíhá v žádosti o přijetí změn, je důležitá pro zlepšení kvality kódu. Sloučit větve pouze prostřednictvím žádostí o přijetí změn, které projdou 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 chvíli trvá. Váš tým by měl souhlasit s tím, co od tvůrců žádostí o přijetí změn a revidujících očekává. Distribuujte odpovědnosti revidujících, abyste mohli sdílet nápady napříč týmem a rozprostřeli znalosti o základu kódu.

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

• Dva revidujícím jsou optimální číslo na základě 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řazování stejných revidujících velkému počtu žádostí o přijetí změn je potřeba věnovat pozornost. Žádosti o přijetí změn fungují lépe, když se v týmu sdílí odpovědnost revidujících.
• Zadejte do popisu dostatek podrobností, abyste mohli revidujícím rychle zobrazit změny.
• Do žádosti o přijetí změn zahrňte sestavení nebo propojenou verzi změn spuštěných ve fázovaném prostředí. Ostatní můžou změny snadno otestovat.

Zajištění vysoké kvality a aktuální hlavní větve

Kód v hlavní větvi by měl projít testy, sestavit vyčistit 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 známou dobrou verzí kódu.

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

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

Tip

Kanál buildu pro vaše žádosti o přijetí změn by měl být rychlý, takže neruší proces kontroly.

Správa vydaných verzí

Větve vydaných verzí můžete použít ke koordinaci a stabilizaci změn ve vydané verzi kódu. Tato větev je dlouhodobá a nesloučí se zpět do hlavní větve v žádosti o přijetí změn, na rozdíl od větví funkcí. Vytvořte tolik větví vydaných verzí, kolik potřebujete. Mějte na paměti, že každá aktivní větev vydané verze představuje jinou verzi kódu, který potřebujete podporovat. Uzamknout větve vydaných verzí, až budete připraveni přestat podporovat konkrétní verzi.

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

Vytvořte větev vydané verze z hlavní větve, když se blížíte k verzi nebo jinému milníku, jako je konec sprintu. Dejte této větvi jasný název, který ji přidružuje k verzi, 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.

Změny portů zpět do hlavní větve

Ujistěte se, že se opraví jak ve vaší větvi vydané verze, tak ve vaší hlavní větvi. Jedním z přístupů je provést opravy ve větvi vydané verze 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ý tým Azure DevOps používá), je vždy provádět změny v hlavní linii a pak je přenést do větve vydané verze. Přečtěte si 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 portováním do hlavní větve. Místo slučování používejte výběr třešní, abyste měli přesnou kontrolu nad tím, která potvrzení se předají 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é nechcete v hlavní větvi.

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

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

Tento pracovní postup větve verze zachovává 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č nepoužíváte značky pro vydané verze?

Jiné pracovní postupy větvení používají značky Git k označení konkrétního potvrzení jako vydané verze. Značky jsou užitečné pro označení bodů v historii jako důležité. Značky představují ve vašem pracovním postupu další kroky, které nejsou potřeba, pokud používáte větve pro vaše vydané verze.

Značky se udržují a odkládají odděleně od potvrzení. Členové týmu můžou snadno zmeškat označování potvrzení a potom se musí vrátit k historii a značku opravit. Můžete také zapomenout na další krok pro nasdílení značky a nechat dalšího vývojáře, který pracuje ze starší verze kódu při podpoře vydané verze.

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

Správa nasazení

Více nasazení kódu můžete zpracovat stejným způsobem, jakým zpracováváte více verzí. Vytvořte jasnou konvenci vytváření názvů, jako je nasazení nebo test výkonnosti, a zacházíte s větvemi prostředí, jako jsou větve vydaných verzí. Váš tým by měl souhlasit s procesem aktualizace větví nasazení pomocí kódu z hlavní větve. Opravy chyb výběru třešně ve větvi nasazení zpět do hlavní větve. Použijte stejný postup jako přenos změn z větve vydané verze.

Výjimkou tohoto doporučení je, že 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í buildů z hlavní větve na cíle nasazení.