Sdílet prostřednictvím

Zásady a nastavení větví systému

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Zásady pro větve pomáhají týmům chránit důležité větve vývoje. Zásady prosazují standardy kvality kódu a řízení změn vašeho týmu. Tento článek popisuje, jak nastavit a spravovat pravidla pro větve. Přehled všech zásad a nastavení úložiště a větví najdete v tématu Nastavení a zásady úložiště Git.

Větev s nakonfigurovanými požadovanými zásadami se nedá odstranit a vyžaduje žádosti o přijetí změn pro všechny změny.

Požadavky

  • Chcete-li nastavit zásady větve, musíte být členem skupiny zabezpečení Project Administrators, nebo mít oprávnění k úpravám zásad na úrovni úložiště. Další informace najdete v tématu Nastavení oprávnění úložiště Git.

  • Pokud chcete ke správě zásad větví použít Azure DevOps CLI az repos policy, postupujte podle kroků v Začít s Azure DevOps CLI.

  • Chcete-li nastavit zásady větve, musíte být členem skupiny zabezpečení Project Administrators, nebo mít oprávnění k úpravám zásad na úrovni úložiště. Další informace najdete v tématu Nastavení oprávnění úložiště Git.

Konfigurace zásad větve

Pokud chcete spravovat pravidla větví, vyberte Repos>Větve a otevřete stránku Větve na webovém portálu.

Snímek obrazovky, který ukazuje položku v nabídce Větve.

Můžete se také dostat k nastavení zásad větve pomocí Projektového nastavení>Úložiště>Zásady>Zásady větve><Název větve>.

Větve, které mají zásady, zobrazují ikonu zásad. Ikonu můžete vybrat a přejít přímo do nastavení zásad větve.

Pokud chcete nastavit zásady větve, vyhledejte větev, kterou chcete spravovat. Seznam můžete procházet nebo hledat svoji větev v poli Prohledat název větve v pravém horním rohu.

Vyberte ikonu Další možnosti vedle větve a pak v místní nabídce vyberte Zásady větve.

Snímek obrazovky znázorňující otevření zásad větve z místní nabídky

Nakonfigurujte zásady na stránce nastavení větve. Popisy a pokyny pro jednotlivé typy zásad najdete v následujících částech.

Vyžadovat minimální počet revidujících

Revize kódu jsou důležité pro projekty vývoje softwaru. Abyste zajistili, že týmy kontrolují a schvalují PR, můžete vyžadovat schválení od minimálního počtu recenzentů. Základní zásada vyžaduje, aby zadaný počet revidujících kód schválil bez zamítnutí.

Chcete-li nastavit zásadu, v části Zásady větve nastavte Požadovat minimální počet kontrolorů na Zapnuto. Zadejte požadovaný počet revidujících a vyberte některou z následujících možností:

Snímek obrazovky znázorňující zásadu Povolit revize kódu

  • Vyberte povolit žadatelům schválit vlastní změny, aby autor žádosti o přijetí mohl hlasovat o schválení. Jinak může autor stále hlasovat Schválit na PR, ale jeho hlas se nezapočítává do minimálního počtu recenzentů.

  • Pokud chcete vynutit oddělení povinností, vyberte Zakázat nejnovějšímu schvalujícímu schválit vlastní změny. Ve výchozím nastavení může každý, kdo má ve zdrojové větvi oprávnění push, přidávat commity i hlasovat o schválení pull requestu. Když vyberete tuto možnost, znamená to, že hlas posledního uživatele, který provádí změny, se nepočítá, i když obvykle může schvalovat své vlastní změny.

  • Vyberte Povolit dokončení, i když někteří recenzenti hlasují pro čekání nebo odmítnutí , aby bylo umožněno dokončení žádosti o přijetí změn, i když někteří recenzenti hlasují proti schválení. Minimální počet revidujících musí stále schvalovat.

  • V části Po zavedení nových změn:
    • Vyberte Vyžadovat alespoň jedno schválení v poslední iteraci k tomu, abyste vyžadovali alespoň jeden schvalovací hlas pro poslední změnu zdrojové větve.
    • Pokud chcete odebrat všechna hlasování o schválení, vyberte Obnovit všechna hlasování schválení (nevynuluje hlasy, které chcete odmítnout nebo počkat), ale hlasy můžete odmítnout nebo počkat, kdykoli se změní zdrojová větev.
    • Výběrem možnosti Resetovat všechny hlasy recenzentů kódu odeberete všechny hlasy recenzentů kdykoli dojde ke změně zdrojové větve, včetně hlasů ke schválení, odmítnutí nebo čekání.
  • V části Po zavedení nových změn:
    • Vyberte Vyžadovat alespoň jedno schválení u každé iterace, abyste u poslední změny zdrojové větve vyžadovali alespoň jeden schvalovací hlas. Schválení uživatele se nezapočítává do žádné předchozí neschválené iterace odeslané tímto uživatelem. V důsledku toho se vyžaduje další schválení poslední iterace jiným uživatelem. V Azure DevOps Serveru 2022.1 a novějším je vyžadováno alespoň jedno schválení každé iterace .
    • Vyberte Vyžadovat alespoň jedno schválení v poslední iteraci k tomu, abyste vyžadovali alespoň jeden schvalovací hlas pro poslední změnu zdrojové větve.
    • Pokud chcete odebrat všechna hlasování o schválení, vyberte Obnovit všechna hlasování schválení (nevynuluje hlasy, které chcete odmítnout nebo počkat), ale hlasy můžete odmítnout nebo počkat, kdykoli se změní zdrojová větev.
    • Výběrem možnosti Resetovat všechny hlasy recenzentů kódu odeberete všechny hlasy recenzentů kdykoli dojde ke změně zdrojové větve, včetně hlasů ke schválení, odmítnutí nebo čekání.

Pokud všechny ostatní zásady projdou, tvůrce může žádost o přijetí změn dokončit, když ji schválí požadovaný počet revidujících.

Kontrola propojených pracovních položek

Pro sledování správy úkolů můžete vyžadovat přidružení mezi PR a pracovními položkami. Propojení pracovních položek poskytuje více kontextu pro změny a zajišťuje, že aktualizace procházejí procesem sledování pracovních položek.

Pokud chcete zásadu nastavit, v části Zásady větve nastavte Možnost Vyhledat propojené pracovní položky na Zapnuto. Toto nastavení vyžaduje, aby pracovní položky byly propojeny s žádostí o přijetí změn, aby se žádost o přijetí změn sloučila. Nastavení Volitelné, aby se zobrazovala upozornění, když nejsou propojené pracovní položky, ale povolte dokončení žádosti o přijetí změn.

Snímek obrazovky s vyžadováním propojených pracovních položek v žádostech o změny.

Kontrola vyřešení komentářů

Zásady kontroly vyřešení komentářů kontrolují, jestli jsou vyřešené všechny komentáře k PR.

Nakonfigurujte zásadu řešení komentářů pro vaší větev nastavením možností Kontrola vyřešení komentářů na Zapnuto. Pak vyberte, jestli se má zásada nastavit jako povinná nebo nepovinná.

Snímek obrazovky s možností Kontrola rozlišení komentáře

Další informace o práci s komentáři k žádostem o přijetí změn viz Kontrola žádostí o přijetí změn.

Omezení typů sloučení

Azure Repos má několik strategií sloučení a ve výchozím nastavení jsou všechny povolené. Konzistentní historii větví můžete udržovat vynucením strategie sloučení pro dokončení pull requestu (PR).

Nastavte omezení typů sloučení na Hodnotu Zapnuto , abyste omezili typy sloučení, které chcete povolit v úložišti.

Snímek obrazovky omezení typů sloučení

  • Základní sloučení (bez rychlého posunu vpřed) vytvoří slučovací commit v cílové větvi, jehož rodičovské větve jsou cílová a zdrojová větev.
  • Squash merge vytvoří lineární historii s jediným potvrzením v cílové větvi se změnami ze zdrojové větve. Přečtěte si další informace o sloučení squashů a o tom, jak ovlivňuje historii větví.
  • Rebase a fast-forward vytvoří lineární historii přehráním zdrojových potvrzení do cílové větve bez potvrzení sloučení.
  • Rebase with merge commit spustí původní commity na cílovou větev a také vytvoří merge commit.

Ověření sestavení

Můžete nastavit zásadu, která vyžaduje, aby změny v PR byly úspěšně sestaveny před dokončením PR. Zásady sestavování snižují přestávky a zajistí, že výsledky testů jsou úspěšné. Zásady vytváření pomáhají i v případě, že ve svých vývojových větvích používáte kontinuální integraci (CI), abyste mohli včas zachytit problémy.

Zásady ověření sestavení zařadí nové sestavení do fronty, když se vytvoří nový pull request (PR) nebo se změny odeslány do existujícího pull requestu (PR), který je zaměřen na větev. Zásada sestavení vyhodnocuje výsledky sestavení a určí, jestli je možné žádost o přijetí změn dokončit.

Důležité

Před specifikací zásad ověřování sestavení mějte připravený build pipeline. Pokud nemáte potrubí, podívejte se na Vytvoření potrubí buildu. Zvolte typ sestavení, který odpovídá vašemu typu projektu.

Přidejte zásadu ověřování sestavení

  1. Vyberte tlačítko + vedle ověření sestavení.

    Snímek obrazovky znázorňující tlačítko Přidat vedle ověření sestavení

  2. Vyplňte formulář Nastavit zásady sestavení:

    Snímek obrazovky s nastavením zásad buildu

    • Vyberte kanál buildu.

    • Volitelně můžete nastavit filtr cesty. Přečtěte si další informace o filtrech cest v zásadách větvových politik.

    • V části Aktivační událost vyberte Automaticky (při každé aktualizaci zdrojové větve) nebo Ruční.

    • V části Požadavek na politiku vyberte Povinné nebo Volitelné. Pokud zvolíte Povinné, sestavení musí být úspěšně dokončeno, aby se dokončily pull requesty. Zvolte Volitelné, pokud chcete poskytnout oznámení o selhání sestavení, a přesto umožnit dokončení pull requestů.

    • Nastavte vypršení platnosti sestavení, abyste měli jistotu, že aktualizace chráněné větve nepřeruší vývoj pro otevřené pull requesty.

      • Ihned při aktualizaci názvu větve: Tato možnost nastaví stav zásad sestavení žádosti o přijetí změn na selhání při každé aktualizaci větve a znovu zařadí sestavení do fronty. Toto nastavení zajistí, že se změny v pull requestu úspěšně sestaví i v případě, že se změní chráněná větev.

        Tato možnost je nejvhodnější pro týmy, jejichž důležité větve mají několik změn. Týmy pracující na zaneprázdněných vývojových větvích mohou považovat čekání na sestavení při každé aktualizaci větve za rušivé.

      • Po <n> hodinách, pokud <je název> větve aktualizován: Tato možnost vyprší aktuální stav zásad, když se chráněná větev aktualizuje, pokud je předávací build starší než zadaná prahová hodnota. Tato možnost představuje kompromis mezi tím, kdy při aktualizaci chráněné větve vždy vyžaduje sestavení a kdy to nikdy nevyžaduje. Tento výběr snižuje počet sestavení, když má vaše chráněná větev časté aktualizace.

      • Nikdy: Aktualizace chráněné větve nemění stav politiky. Tato hodnota snižuje počet sestavení, ale může způsobit problémy při uzavírání pull requestů, které nebyly nedávno aktualizovány.

    • Zadejte volitelný zobrazovaný název pro tuto zásadu sestavení. Tento název identifikuje zásadu na stránce Zásady větve. Pokud nezadáte zobrazovaný název, zásada použije název kanálu buildu.

  3. Zvolte Uložit.

Když vlastník PR odešle změny, které se úspěšně sestaví, stav politiky se aktualizuje.

Pokud máte zásadu sestavení pro Okamžitě když je <název větve> aktualizovaný nebo Po <n> hodinách, pokud byl <název větve> aktualizován, stav zásad se aktualizuje při aktualizaci chráněné větve, pokud předchozí build už není platný.

Kontroly stavu

Externí služby mohou použít rozhraní Status API pro PR k publikování podrobného stavu vašich žádostí o přijetí změn. Pravidla větve pro dodatečné služby umožňují těmto externím službám účastnit se pracovního postupu žádosti o přijetí změn a nastavit požadavky na pravidla.

Snímek obrazovky s možností Vyžadovat schválení externích služeb

Pokyny ke konfiguraci této zásady najdete v tématu Konfigurace zásad větve pro externí službu.

Automatické zahrnutí recenzentů kódu

Kontrolory můžete automaticky přidávat k žádostem o přijetí změn, které upravují soubory v konkrétních adresářích a souborech, nebo ke všem žádostem o přijetí změn v úložišti.

  1. + Vyberte tlačítko vedle automaticky zahrnutých recenzentů.

    Snímek obrazovky znázorňující Přidat požadované recenzenty.

  2. Vyplňte obrazovku Přidat novou politiku recenzenta.

    Snímek obrazovky znázorňující obrazovku Zásady pro přidání nového recenzenta

    • Přidejte lidi a skupiny do revidujících.

    • Vyberte Volitelné, pokud chcete přidat revidenty automaticky, ale nevyžadujete jejich schválení pro dokončení žádosti o přijetí změn.

      Nebo vyberte Povinné, pokud nelze žádosti o přijetí změn dokončit do:

      • Každý jednotlivec přidaný jako kontrolor změny schválí.
      • Změny schválí alespoň jedna osoba v každé skupině přidaná jako kontrolor.
      • Pokud je vyžadována pouze jedna skupina, minimální počet členů, které určíte, schválí změny.

    • Zadejte soubory a složky, které mají automaticky zahrnuty revizory. Nechte toto pole prázdné, aby byly vyžadovány schvalovatelé pro všechny pull requesty v této větvi.

    • Pokud mohou vlastníci žádostí o přijetí změn hlasovat pro schválení vlastních žádostí, aby splnili tuto politiku, vyberte Povolit žadatelům schválit vlastní změny.

    • Můžete zadat zprávu informačního kanálu o aktivitách, která se zobrazí v žádosti o přijetí změn.

  3. Zvolte Uložit.

Obejití zásad poboček

V některých případech možná budete muset obejít požadavky zásad. Oprávnění k obcházení vám umožní přenést změny přímo do větve nebo dokončit pull requesty, které nevyhovují zásadám větvení. Uživateli nebo skupině můžete udělit oprávnění k obejití. Můžete nastavit působnost oprávnění pro obejití pro celý projekt, úložiště nebo jednotlivou větev.

Dvě oprávnění umožňují uživatelům obejít zásady větví různými způsoby:

  • Zásady obejití při dokončování žádostí o přijetí změn se vztahují pouze na dokončení žádosti o přijetí změn. Uživatelé s tímto oprávněním mohou provádět žádosti o přijetí změn i v případě, že žádosti o přijetí změn nesplňují zásady.

  • Obcházení zásad při přesunech se vztahuje na přesuny z místních úložišť a úpravy prováděné na webu. Uživatelé s tímto oprávněním můžou odesílat změny přímo do chráněných větví bez splnění požadavků zásad.

Snímek obrazovky znázorňující oprávnění k vynucování zásad obejití

Další informace o správě těchto oprávnění najdete v tématu Oprávnění Gitu.

Důležité

Při udělování možnosti obejít zásady, zejména na úrovni úložiště a projektu, buďte opatrní. Zásady jsou základním kamenem správy zabezpečeného a vyhovujícího zdrojového kódu.

Filtry cest

Několik zásad větví nabízí filtry cest. Pokud je nastavený filtr cesty, zásada se vztahuje pouze na soubory, které odpovídají filtru cesty. Ponechání tohoto pole prázdné znamená, že zásada se vztahuje na všechny soubory ve větvi.

Můžete zadat absolutní cesty (cesta musí začínat buď znakem / , nebo zástupným znakem) a zástupné znaky. Příklady:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Můžete zadat více cest pomocí ; jako oddělovače. Příklad:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Cesty s předponou ! jsou vyloučeny, pokud by jinak byly zahrnuty. Příklad:

  • /WebApp/*;!/WebApp/Tests/*zahrnuje všechny soubory kromě souborů v /WebApp/WebApp/Tests
  • !/WebApp/Tests/* určuje žádné soubory, protože nic není zahrnuto jako první.

Pořadí filtrů je významné. Filtry se použijí zleva doprava.

Otázky a odpovědi

Můžu změny přesunout přímo do větví, které mají politiky větví?

Změny nemůžete odesílat přímo do větví s požadovanými zásadami větví, pokud nemáte oprávnění k obcházení zásad větví. Změny těchto větví lze provádět pouze prostřednictvím pull requestů. Můžete změny nasdílet přímo do větví, které mají volitelné zásady, pokud nemají žádné povinné zásady větví.

Co je automatické dokončování?

Žádosti o přijetí změn do větví s nakonfigurovanými zásadami větví mají tlačítko Nastavit automatické dokončování . Tuto možnost vyberte, pokud chcete automaticky dokončit pull request, jakmile budou splněny všechny zásady. Automatické dokončování je užitečné, když neočekáváte žádné problémy se změnami.

Kdy jsou zkontrolovány podmínky zásad větve?

Zásady větví se na serveru znovu vyhodnotí, když vlastníci pull requestů provedou změny a při hlasování recenzentů. Pokud zásada aktivuje sestavení, stav sestavení se nastaví na čekání, dokud nebude sestavení dokončeno.

Mohu v zásadách větve používat definice sestavení XAML?

Ne, v zásadách větve nemůžete použít definice sestavení XAML.

Jaké zástupné znaky můžu použít pro požadované kontrolory kódu?

Jedna hvězdička * odpovídá libovolnému počtu znaků, včetně normálních lomítek / i zpětných lomítek \. Otazníky ? odpovídají jakémukoli jednomu znaku.

Příklady:

  • *.sql odpovídá všem souborům s příponou .sql .
  • /ConsoleApplication/* odpovídá všem souborům ve složce s názvem ConsoleApplication.
  • /.gitattributes odpovídá souboru.gitattributes* v kořenovém adresáři úložiště.
  • */.gitignore odpovídá jakémukoli souboru .gitignore v úložišti.

Rozlišují se malá a velká písmena v cestách požadovaných pro kontrolory kódu?

Ne, zásady větví nerozlišují malá a velká písmena.

Jak můžu nakonfigurovat více uživatelů jako požadovaných revidujících, ale vyžadovat, aby schvalovali jenom jeden z nich?

Uživatele můžete přidat do skupiny a potom přidat skupinu jako recenzenta. Každý člen skupiny může poté schválit splnění požadavku dané zásady.

Mám oprávnění k obejití zásad. Proč se stále zobrazují problémy ve stavu pull requestu?

Nakonfigurované zásady se vždy vyhodnocují pro změny u pull requestů. Pro uživatele, kteří mají oprávnění k obejití zásad, je nahlášený stav zásad pouze informativní. Pokud uživatel s oprávněními k obejití schválí, stav selhání neblokuje dokončení pull requestu.

Proč nemůžu dokončit vlastní žádosti o přijetí změn, když je nastavená možnost Povolit žadatelům schválit vlastní změny?

Zásady Vyžadovat minimální počet revidujících a automaticky zahrnuté zásady kontrolorů mají možnosti povolit žadatelům schválit vlastní změny. Nastavení se v každé zásadě vztahuje pouze na tuto zásadu. Nastavení nemá vliv na ostatní zásady.

Například váš pull request má nastavené následující politiky:

  • Vyžadovat minimální počet revidujících vyžaduje alespoň jednoho revidujícího.
  • Automaticky zahrnutí kontroloři vyžadují vás nebo tým, ve kterém jste, jako kontrolora.
  • Automaticky zahrnutý revidující má povoleno žadatelům schválit vlastní změny.
  • Vyžadovat minimální počet revidujících nemá povolení umožnit žadatelům schvalovat jejich vlastní změny.

V tomto případě vaše schválení splňuje podmínky pro automaticky zahrnuté kontrolory, ale ne splnění podmínky pro požadavek na minimální počet kontrolorů, takže nemůžete dokončit pull request.

Můžou se zde vyskytovat i další zásady, jako například Zakázat nejnovějšímu autorovi změn schválení vlastních změn, které vám brání ve schvalování vlastních změn, i když je nastavená možnost Povolit žadatelům schválit vlastní změny.

Co se stane, když cesta ve filtrech cest nezačíná / nebo se zástupným znakem?

Cesta ve filtrech cest, která nezačíná znakem / nebo zástupným znakem, nemá žádný účinek a filtr cesty se vyhodnotí, jako by ta cesta nebyla zadána. Taková cesta nemůže odpovídat / absolutní cestě k souboru, která začíná.

  • Last updated on