Přijměte strategii 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ů:

• Používejte větve funkcí pro všechny nové funkce a opravy chyb.
• Sloučení funkčních větví do hlavní větve pomocí pull requestů.
• 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žívejte funkční větve 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. Funkční větve 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í:

• uživatelé/uživatelské_jméno/popisek
• uživatelé/uživatelské_jméno/pracovní_položka
• oprava chyby nebo popis
• funkce/feature-name
• feature/feature-area/feature-name
• hotfix a 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žijte feature flagy 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 pull requestu, je klíčová pro zlepšení kvality kódu. Pouze slučujte větve prostřednictvím pull requestů, které prošly 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 chvíli trvá. Váš tým by měl mít jasnou představu o tom, co se očekává od tvůrců žádostí o sloučení a posuzovatelů. Distribuujte odpovědnosti revidujících, abyste mohli sdílet nápady napříč týmem a rozprostřeli znalosti o základu kódu.

Doporučení 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, začleňte pull requesty do toho, co už děláte.
• Dávejte pozor při přiřazování stejných recenzentů velkému počtu žádostí o přijetí změn. Pull requesty fungují lépe, když se odpovědnosti recenzentů sdílejí v týmu.
• Zadejte do popisu dostatek podrobností, abyste mohli revidujícím rychle zobrazit změny.
• Do pull requestu zahrňte sestavení nebo propojenou verzi vašich změn spuštěných v testovacím prostředí. Ostatní můžou změny snadno otestovat.

Udržujte vysokou kvalitu up-to-date hlavní větev.

Kód v hlavní větvi by měl úspěšně projít testy, sestavit se bez chyb 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 pravidlo větve pro vaší hlavní větev, které:

• Vyžaduje pull request pro 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á revidenta při vytvoření pull requestu. Přidaní členové týmu zkontrolují kód a komentují změny v žádosti o přijetí změn.
• Vyžaduje úspěšné sestavení pro dokončení pull requestu. Kód spojený do hlavní větve by měl být sestaven bez problémů.

Návod

Kanál sestavení pro vaše pull requesty by měl být rychlý, aby nenarušoval 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 pull requestu, na rozdíl od funkčních větví. 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 vydávací větev z hlavní větve, když se blížíte k vydání nebo nějakému 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 pro opravu chyb nalezených v release větvi a sloučte je zpět do release větve pomocí pull requestu.

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 vydávací větvi a jejich přenosem do hlavní větve. Místo slučování používejte vybírání konkrétních commitů, abyste mohli přesně kontrolovat, které commity se předají zpět do hlavní větve. Spojení větve pro vydání 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čte funkční větev zpět do hlavní větve v druhém pull requestu.

Tento pracovní postup vývojové větve zachovává pilíře základního pracovního postupu nedotčeny: vývojové větve, pull requesty a silnou hlavní větev, která má vždy nejnovější verzi kódu.

Proč nevyužít značky pro vydání?

Jiné pracovní postupy větvení používají Git značky 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é. 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 odesílají odděleně od commitů. Členové týmu mohou snadno opomenout označit potvrzení a potom se musí vrátit k historii, aby opravili značku. Můžete také zapomenout na další krok pro odeslání značky, a tím nechat dalšího vývojáře pracovat ze starší verze kódu při podpoře vydání.

Strategie větve pro vydání rozšiřuje základní pracovní postup větve funkcí pro správu vydání. Váš tým nemusí přijmout žádný jiný nový proces správy verzí kromě cherry-pick pro přenos změn.

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 pojmenování, jako je deploy/performance-test, a zacházejte s větvemi prostředí, jako s větvemi pro vydání. Váš tým by měl souhlasit s procesem aktualizace větví nasazení pomocí kódu z hlavní větve. Přetáhněte opravy chyb 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í.