Megosztás a következőn keresztül:


Ágszabályzatok és -beállítások

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

A fiókszabályzatok segítenek a csapatoknak megvédeni fontos fejlesztési ágaikat . A szabályzatok betartatják a csapat kódminőségét és változáskezelési szabványait. Ez a cikk a fiókszabályzatok beállítását és kezelését ismerteti. Az adattár- és ágházirendek és -beállítások áttekintéséért tekintse meg a Git-adattár beállításait és szabályzatait.

A konfigurált kötelező szabályzatokkal rendelkező ág nem törölhető, és lekéréses kérelmeket (PRs) igényel az összes módosításhoz.

Előfeltételek

  • A fiókházirendek beállításához a Projektgazdák biztonsági csoport tagjának kell lennie, vagy adattárszintű szerkesztési szabályzatokkal kell rendelkeznie. További információ: Git-adattárengedélyek beállítása.

  • Ha az Azure DevOps CLI az repos policy parancsaival szeretné kezelni a fiókszabályzatokat, kövesse az Azure DevOps parancssori felület használatának első lépéseit.

  • A fiókházirendek beállításához a Projektgazdák biztonsági csoport tagjának kell lennie, vagy adattárszintű szerkesztési szabályzatokkal kell rendelkeznie. További információ: Git-adattárengedélyek beállítása.

Ágszabályzatok konfigurálása

Az ágszabályzatok kezeléséhez válassza a Tárfiókok> lehetőséget az Ágak lap megnyitásához a webportálon.

Képernyőkép az Ágak menüelemről.

Az ágházirend-beállításokat a Project Settings>Adattárházházirendek>>fiókszabályzatának<>ágnevével >is elérheti.

A szabályzatokkal rendelkező ágak házirendikont jelenítenek meg. Az ikont választva közvetlenül az ág házirendbeállításaihoz léphet.

Az ágszabályzatok beállításához keresse meg a kezelni kívánt ágat. A jobb felső sarokban található Keresés ágnév mezőben tallózhat a listában, vagy megkeresheti az ágat.

Válassza az ág melletti További beállítások ikont, majd a helyi menüBen válassza az Ágszabályzatok lehetőséget.

Képernyőkép a helyi menü ágszabályzatainak megnyitásáról.

Keresse meg az ágat a lapon. Böngészhet a listában, vagy megkeresheti az ágat a jobb felső sarokban található Minden ág keresése párbeszédpanelen.

Képernyőkép az Ágak lapról.

Válassza a ... gombot. Válassza a Helyi menü Ágszabályzatok elemét.

Képernyőkép a helyi menü ágszabályzatainak megnyitásáról.

Szabályzatok konfigurálása az ág beállítások lapján. Az egyes szabályzattípusok leírását és utasításait az alábbi szakaszokban találja.

Konfigurálja a szabályzatokat a Szabályzatok lapon. Az egyes szabályzattípusok leírását a következő szakaszokban találja. Válassza a Módosítások mentése lehetőséget az új szabályzatkonfiguráció alkalmazásához.

Képernyőkép a Szabályzatok lapról.

A véleményezők minimális számának megkövetelése

A kód áttekintése fontos a szoftverfejlesztési projektekhez. Annak biztosítása érdekében, hogy a csapatok felülvizsgálják és jóváhagyják a kérelemkéréseket, minimális számú véleményezőtől kérhet jóváhagyást. Az alapszintű szabályzat megköveteli, hogy adott számú felülvizsgáló hagyja jóvá a kódot, elutasítás nélkül.

A szabályzat beállításához a Fiókszabályzatok csoportban állítsa be a Véleményezők minimális számát Be értékre. Adja meg a szükséges számú véleményezőt, és válasszon az alábbi lehetőségek közül:

Képernyőkép a Kódkontraszt-ellenőrzési szabályzat engedélyezéséről.

  • Válassza az Engedélyezés a kérelmezők számára, hogy jóváhagyják a saját módosításaikat , hogy a pr létrehozója szavazhasson a jóváhagyásáról. Ellenkező esetben az alkotó továbbra is szavazhat a Jóváhagyás a kérelemre, de a szavazatuk nem számít bele a véleményezők minimális számába.

  • Válassza a Legutóbbi leküldés tiltása a saját módosítások jóváhagyásától a vámok elkülönítésének kikényszerítéséhez. Alapértelmezés szerint bárki, aki leküldéses engedéllyel rendelkezik a forráságban, hozzáadhat véglegesítéseket, és szavazhat a pr-jóváhagyásra. Ha ezt a lehetőséget választja, az azt jelenti, hogy a legutóbbi leküldéses szavazás nem számít, még akkor sem, ha általában jóváhagyhatják a saját módosításaikat.

  • Válassza a Befejezés engedélyezése lehetőséget, még akkor is, ha egyes véleményezők várakozásra vagy elutasításra szavaznak a pr befejezésének engedélyezéséhez, még akkor is, ha egyes véleményezők a jóváhagyás ellen szavaznak. A véleményezők minimális számát továbbra is jóvá kell hagyni.

  • Az új módosítások leküldésének helye alatt:
    • Válassza a Legalább egy jóváhagyás megkövetelése az utolsó iterációhoz , hogy legalább egy jóváhagyási szavazatot igényeljen az utolsó forráság-módosításhoz.
    • Válassza az Összes jóváhagyási szavazat alaphelyzetbe állítása (nem állítja vissza a szavazatokat az elutasításra vagy várakozásra), hogy eltávolítsa az összes jóváhagyási szavazatot, de a forráság minden változásakor tartsa meg az elutasításra vagy várakozásra vonatkozó szavazatokat.
    • Ha a forráság megváltozik, a jóváhagyandó, elutasító vagy várakozási szavazatokat is beleértve, válassza az Összes kód felülvizsgálójának szavazatának alaphelyzetbe állítása lehetőséget.
  • Az új módosítások leküldésének helye alatt:
    • Válassza a Legalább egy jóváhagyás megkövetelése minden iterációban , hogy legalább egy jóváhagyási szavazatra legyen szükség az utolsó forráság-módosításra. A felhasználó jóváhagyása nem számít bele a felhasználó által leküldett korábbi nem jóváhagyott iterációkba. Ennek eredményeképpen egy másik felhasználónak az utolsó iterációra vonatkozó jóváhagyást kell elvégeznie. Minden iterációhoz legalább egy jóváhagyás szükséges az Azure DevOps Server 2022.1 és újabb verzióiban.
    • Válassza a Legalább egy jóváhagyás megkövetelése az utolsó iterációhoz , hogy legalább egy jóváhagyási szavazatot igényeljen az utolsó forráság-módosításhoz.
    • Válassza az Összes jóváhagyási szavazat alaphelyzetbe állítása (nem állítja vissza a szavazatokat az elutasításra vagy várakozásra), hogy eltávolítsa az összes jóváhagyási szavazatot, de a forráság minden változásakor tartsa meg az elutasításra vagy várakozásra vonatkozó szavazatokat.
    • Ha a forráság megváltozik, a jóváhagyandó, elutasító vagy várakozási szavazatokat is beleértve, válassza az Összes kód felülvizsgálójának szavazatának alaphelyzetbe állítása lehetőséget.

Jelölje be a Kódellenőrzések megkövetelése jelölőnégyzetet

  • Ha a kérelmezők jóváhagyhatják a saját módosításaikat , akkor a lekéréses kérelem létrehozója továbbra is szavazhat a Jóváhagyás a lekéréses kérelemre, de a szavazatuk nem számít bele a véleményezők minimális számába.
  • Ha bármelyik véleményező elutasítja a módosításokat, a lekéréses kérelem csak akkor fejeződhet be, ha ön a Befejezés engedélyezése lehetőséget választja , még akkor sem, ha egyes véleményezők várakozásra vagy elutasításra szavaznak.
  • Az új módosítások forráságba való leküldésekor alaphelyzetbe állíthatja a kód felülvizsgálójának szavazatát. Válassza az Új kód felülvizsgálója szavazatok visszaállítása lehetőséget, ha új módosítások történnek.

Ha az összes többi szabályzat megfelel, a létrehozó a szükséges számú véleményező jóváhagyása után végrehajthatja a lekéréses kérelmet.

Csatolt munkaelemek keresése

A munkaelem-kezelés nyomon követéséhez társítást igényelhet a PRs és a munkaelemek között. A munkaelemek összekapcsolása több kontextust biztosít a módosításokhoz, és biztosítja, hogy a frissítések végighaladnak a munkaelem-követési folyamaton.

A szabályzat beállításához a Fiókszabályzatok területen állítsa be a Csatolt munkaelemek ellenőrzése beállítást. Ez a beállítás megköveteli, hogy a munkaelemek egy pr-hez legyenek csatolva az egyesítéshez. Ha nincs csatolt munkaelem, a lekéréses kérelem befejezésének engedélyezése a beállítás megadása nem kötelező .

Képernyőkép a csatolt munkaelemek lekéréses kérelmekben való megköveteléséről.

Csatolt munkaelemek megkövetelése a lekéréses kérelmekben

Megjegyzésfeloldás keresése

A Megjegyzésfeloldási szabályzat ellenőrzi, hogy az összes pr-megjegyzés feloldva van-e.

Az ág megjegyzésfeloldási szabályzatának konfigurálásához állítsa be a Megjegyzésfeloldás ellenőrzése beállítást a Be értékre. Ezután válassza ki, hogy kötelezővé vagy nem kötelezővé kívánja tenni a szabályzatot.

Képernyőkép a megjegyzésfeloldás ellenőrzéséről.

További információ a lekéréses kérelmek megjegyzéseinek használatáról: Lekéréses kérelmek áttekintése.

Az ág megjegyzésfeloldási szabályzatának konfigurálásához válassza a Megjegyzésfeloldás ellenőrzése lehetőséget.

Megjegyzésfeloldás keresése

További információ a lekéréses kérelmek megjegyzéseinek használatáról: Lekéréses kérelmek áttekintése.

Egyesítési típusok korlátozása

Az Azure Repos több egyesítési stratégiával rendelkezik, és alapértelmezés szerint mindegyik engedélyezett. Konzisztens ágelőzményeket tarthat fenn egy egyesítési stratégia kényszerítésével a lekéréses kérelem lekéréséhez.

Az adategyesítési típusok korlátjának beállítása Be értékre, hogy korlátozza az adattárban engedélyezni kívánt egyesítési típusokat.

Képernyőkép az egyesítési típusok korlátozásáról.

  • Az alapszintű egyesítés (nem gyorsított) egyesítési véglegesítést hoz létre abban a célban, amelynek a szülei a cél- és forráságak.
  • A squash-egyesítés egy lineáris előzményt hoz létre egyetlen véglegesítéssel a célágban a forráság módosításaival. További információ a fallabda-egyesítésről és arról, hogy ez hogyan befolyásolja az ágak előzményeit.
  • Az újrabázis és a gyors továbbítás lineáris előzményt hoz létre úgy, hogy a forrás-véglegesítéseket a célágra továbbítja egyesítési véglegesítés nélkül.
  • Az egyesítési véglegesítés újrabázisa visszajátssza a forrás véglegesítéseit a célra, és létrehoz egy egyesítési véglegesítést is.

Feljegyzés

Ez a funkció az Azure DevOps Server 2020 és újabb verziókhoz érhető el.

Egyesítési stratégia kényszerítése

Konzisztens ágelőzmények fenntartása egy egyesítési stratégia kényszerítésével, amikor egy lekéréses kérelem befejeződik. Válassza az Egyesítési stratégia kényszerítése lehetőséget, és válasszon egy lehetőséget, amely megköveteli, hogy a lekéréses kérelmek egyesüljenek ezzel a stratégiával.

Egyesítési követelmények beállítása

  • Nincs gyors egyesítés – Ez a beállítás egyesíti a forráság véglegesítési előzményeit, amikor a lekéréses kérelem bezárul, és létrehoz egy egyesítési véglegesítést a célágban.
  • Squash-egyesítés – Az összes lekéréses kérés végrehajtása squash-egyesítéssel, egyetlen véglegesítés létrehozása a célágban a forráság módosításaival. További információ a fallabda-egyesítésről és arról, hogy ez hogyan befolyásolja az ágelőzményeket.

Build érvényesítése

Beállíthat egy szabályzatot, amely megköveteli, hogy a lekéréses kérelem módosítása sikeres legyen, mielőtt a kérelemkérés befejeződik. Szabályzatok létrehozása csökkenti a töréseket, és megőrzi a teszteredményeket. A szabályzatok létrehozása akkor is segít, ha folyamatos integrációt (CI) használ a fejlesztési ágakon a problémák korai észleléséhez.

A buildérvényesítési szabályzatok új buildeket várnak új lekéréses kérelem létrehozásakor, vagy a módosításokat egy meglévő, az ágat célzó pr-be küldik. A buildelési szabályzat kiértékeli a builderedményeket annak megállapításához, hogy a lekérés befejezhető-e.

Fontos

A buildérvényesítési szabályzat megadása előtt buildelési folyamattal kell rendelkeznie. Ha nem rendelkezik folyamatsal, olvassa el a buildelési folyamat létrehozása című témakört. Válassza ki a projekttípusnak megfelelő buildtípust.

Buildérvényesítési szabályzat hozzáadása

  1. Válassza a + Build érvényesítése gombot.

    Képernyőkép a Build érvényesítése mellett található Hozzáadás gombról.

  2. Töltse ki a Build szabályzat beállítása űrlapot:

    Képernyőkép a buildszabályzat beállításairól.

    • Válassza ki a Build folyamatot.

    • Lehetőség van elérésiút-szűrő beállítására. További információ a fiókszabályzatok elérésiút-szűrőiről .

    • Az Eseményindító területen válassza az Automatikus (a forráság frissítésekor) vagy a Manuális lehetőséget.

    • A Házirend követelménye területen válassza a Kötelező vagy a Nem kötelező lehetőséget. Ha a Kötelező lehetőséget választja, a buildeknek sikeresen be kell fejeződniük a PRS-ek elvégzéséhez. Válassza a Választható lehetőséget, ha értesítést szeretne adni a buildelési hibáról, de továbbra is engedélyezi a PRS-ek befejezését.

    • Állítson be egy build lejárati dátumot, hogy a védett ág frissítései ne szegik meg a megnyitott PRS-ek módosításait.

      • Közvetlenül az <ágnév> frissítésekor: Ez a beállítás azt állítja be, hogy a lekéréses kérelem-létrehozási szabályzat állapota sikertelen legyen az ág frissítésekor, és újra lekérdezi a buildet. Ez a beállítás biztosítja, hogy a pr-módosítások akkor is sikeresen létrejönnek, ha a védett ág megváltozik.

        Ez a lehetőség azoknak a csapatoknak ajánlott, amelyek fontos ágai kevés módosítást hajtanak végre. Az elfoglalt fejlesztési ágakban dolgozó csapatok zavarónak találhatják, hogy minden alkalommal várják a buildet, amikor az ág frissül.

      • Az ágnév> frissítése után <n> óra elteltével<: Ez a beállítás lejár az aktuális szabályzat állapota, amikor a védett ág frissül, ha az átmenő build régebbi a megadott küszöbértéknél. Ez a lehetőség kompromisszumot jelent a védelemmel ellátott ág frissítésekkor mindig vagy soha nem igényel buildelést. Ez a választás csökkenti a buildek számát, ha a védett ág gyakran frissül.

      • Soha: A védett ág frissítései nem módosítják a szabályzat állapotát. Ez az érték csökkenti a buildek számát, de problémákat okozhat a nemrég nem frissített PRS-ek végrehajtásakor.

    • Adjon meg egy választható megjelenítendő nevet ehhez a buildelési szabályzathoz. Ez a név azonosítja a szabályzatot a Fiókházirendek lapon. Ha nem ad meg megjelenítendő nevet, a szabályzat a buildelési folyamat nevét használja.

  3. Válassza a Mentés lehetőséget.

Amikor a lekéréses kérelem tulajdonosa leküldi a sikeresen buildelt módosításokat, a szabályzat állapota frissül.

Ha a fióknév> frissítésekor azonnal<, vagy n> óra elteltével<, ha <az ág neve> frissült, akkor a szabályzat állapota akkor frissül, amikor a védett ág frissül, ha az előző build már nem érvényes.

Feljegyzés

Ez a funkció az Azure DevOps Server 2020 és újabb verziókhoz érhető el.

Állítson be egy olyan szabályzatot, amely a lekéréses kérelem módosításait igényli a védett ág sikeres létrehozásához, mielőtt a lekéréses kérelem befejeződhet. Szabályzatok létrehozása csökkenti a töréseket, és megőrzi a teszteredményeket. A szabályzatok létrehozása akkor is segít, ha folyamatos integrációt (CI) használ a fejlesztési ágakon a problémák korai észleléséhez.

Ha engedélyezve van egy buildérvényesítési szabályzat, a rendszer új lekéréses kérelem létrehozásakor vagy az ágat célzó meglévő lekéréses kérelemre küldi a módosításokat. A buildelési szabályzat ezután kiértékeli a build eredményeit annak megállapításához, hogy a lekéréses kérelem teljesíthető-e.

Fontos

A buildérvényesítési szabályzat megadása előtt rendelkeznie kell egy builddefinícióval. Ha nem rendelkezik ilyenrel, olvassa el a Builddefiníció létrehozása című témakört, és válassza ki a projekttípusnak megfelelő buildtípust.

Buildelési szabályzat hozzáadása

Válassza a Buildszabályzat hozzáadása lehetőséget, és konfigurálja a beállításokat a Buildelési szabályzat hozzáadása területen.

Szabályzatbeállítások létrehozása

  1. Válassza ki a builddefiníciót.

  2. Válassza ki az eseményindító típusát. Válassza az Automatikus (a forráság frissítésekor) vagy a Manuális lehetőséget.

  3. Válassza ki a szabályzat követelményét. Ha a Kötelező lehetőséget választja, a buildeknek sikeresen be kell fejeződniük a lekéréses kérelmek teljesítéséhez. Válassza a Nem kötelező lehetőséget, ha értesítést szeretne küldeni a buildelési hibáról, de továbbra is engedélyezi a lekéréses kérelmek teljesítését.

  4. Állítson be egy build lejárati dátumot, hogy a védett ág frissítései ne szegik meg a nyitott lekéréses kérelmek módosításait.

    • Azonnali frissítés: branch name Ezzel a beállítással a lekéréses kérelem buildszabályzatának állapota meghiúsul a védett ág frissítésekor. Készítsen újra egy buildet a build állapotának frissítéséhez. Ez a beállítás biztosítja, hogy a lekéréses kérelmek módosításai sikeresen létrejönnek, még akkor is, ha a védett ág megváltozik. Ez a lehetőség azoknak a csapatoknak a legjobb, amelyek fontos ágai kisebb mennyiségű módosítással rendelkeznek. Az elfoglalt fejlesztési ágakban dolgozó csapatok zavarónak találhatják, ha megvárják a buildek befejezését a védett ág minden frissítésekor.
    • Órák elteltével n , ha branch name frissült: Ez a beállítás lejár az aktuális szabályzat állapota, amikor a védett ág frissül, ha az átmenő build régebbi a megadott küszöbértéknél. Ez a lehetőség kompromisszumot jelent a védelemmel ellátott ág frissítésekkor történő és soha nem igényelt buildek közötti kompromisszumok között. Ez a választás kiválóan alkalmas a buildek számának csökkentésére, ha a védett ág gyakran frissül.
    • Soha: A védett ág frissítései nem módosítják a szabályzat állapotát. Ez az érték csökkenti az ág buildjeinek számát. Problémákat okozhat, ha a közelmúltban nem frissített lekéréses kérelmeket zár be.
  5. Adjon meg egy választható megjelenítendő nevet ehhez a buildelési szabályzathoz. Ez a név azonosítja a szabályzatot a Fiókházirendek lapon. Ha nem ad meg megjelenítendő nevet, a szabályzat a builddefiníció nevét használja.

  6. Válassza a Mentés lehetőséget.

Amikor a tulajdonos leküldi a sikeres buildelési módosításokat, a szabályzat állapota frissül. Ha azonnali branch name frissítéssel rendelkezik, vagy n ha branch name a módosított buildelési szabályzatot választotta, a szabályzat állapota akkor frissül, amikor a védett ág frissül, ha a legutóbbi build már nem érvényes.

Állapotellenőrzések

A külső szolgáltatások a PR Status API használatával részletes állapotot tehetnek közzé a kérelemirodákban. A további szolgáltatások ágszabályzata lehetővé teszi, hogy ezek a külső szolgáltatások részt vegyenek a pr munkafolyamatban, és szabályzatkövetelményeket állapítsanak meg.

Képernyőkép a külső szolgáltatások jóváhagyásának megköveteléséről.

A szabályzat konfigurálásával kapcsolatos utasításokért lásd : Ágházirend konfigurálása külső szolgáltatáshoz.

Külső szolgáltatások jóváhagyásának megkövetelése

A külső szolgáltatások a PR Status API használatával részletes állapotot tehetnek közzé a kérelemirodákban. A további szolgáltatások ágszabályzata lehetővé teszi, hogy ezek a külső szolgáltatások részt vehessenek a pr munkafolyamatban, és szabályzatkövetelményeket állapítsanak meg.

Külső szolgáltatások jóváhagyásának megkövetelése

A szabályzat konfigurálásával kapcsolatos utasításokért lásd : Ágházirend konfigurálása külső szolgáltatáshoz.

Kód véleményezők automatikus belefoglalása

Automatikusan hozzáadhat véleményezőket az adott könyvtárakban és fájlokban lévő fájlokat módosító lekéréses kérelmekhez, illetve az adattárban lévő összes lekéréses kérelemhez.

  1. Válassza az + Automatikusan belefoglalt véleményezők gombot.

    Képernyőkép a szükséges véleményezők hozzáadásáról.

  2. Töltse ki az Új véleményező hozzáadása szabályzat képernyőt.

    Képernyőkép az Új véleményező hozzáadása szabályzat képernyőről.

    • Személyek és csoportok hozzáadása a véleményezőkhöz.

    • Válassza az Opcionális lehetőséget, ha automatikusan szeretne véleményezőket hozzáadni, de nem igényel jóváhagyást a lekéréses kérelem befejezéséhez.

      Vagy válassza a Kötelező lehetőséget, ha a lekéréses kérelmek csak a következő időpontig hajthatóak végre:

      • Minden véleményezőként hozzáadott személy jóváhagyja a módosításokat.
      • A korrektúraként hozzáadott csoportokban legalább egy személy jóváhagyja a módosításokat.
      • Ha csak egy csoportra van szükség, a megadott minimális számú tag jóváhagyja a módosításokat.
    • Adja meg az automatikusan belefoglalt véleményezőket igénylő fájlokat és mappákat. Hagyja üresen ezt a mezőt, ha az ágban lévő összes lekéréses kérelem véleményezőit szeretné megkövetelni.

    • Ha a lekéréses kérelmek tulajdonosai szavazhatnak a saját lekéréses kéréseik jóváhagyására, a szabályzat teljesítéséhez válassza a Kérelmezők jóváhagyásának engedélyezése lehetőséget .

    • Megadhat egy tevékenységcsatorna-üzenetet , amely megjelenik a lekéréses kérelemben.

  3. Válassza a Mentés parancsot.

Feljegyzés

Ez a funkció az Azure DevOps Server 2020 és újabb verziókhoz érhető el.

Válassza ki a véleményezőket az adattárban lévő adott könyvtárakhoz és fájlokhoz.

Adja meg az elérési utat és a szükséges véleményezőket

Ezek a véleményezők automatikusan hozzáadódnak a lekéréses kérelmekhez, amelyek ezen útvonalak mentén módosítják a fájlokat. Tevékenységcsatorna-üzenetet is megadhat.

Automatikus véleményezők hozzáadása

Ha a Kötelező lehetőséget választja, a lekéréses kérelem csak a következő időpontig hajtható végre:

  • Minden, az elérési úthoz véleményezőként hozzáadott felhasználó jóváhagyja a módosításokat.
  • Az elérési úthoz hozzáadott összes csoport legalább egy tagja jóváhagyja a módosításokat.
  • Az elérési úthoz hozzáadott összes csoporthoz megadott véleményezők száma jóváhagyja a módosításokat.

A szükséges véleményezők automatikusan hozzáadódnak

Válassza az Opcionális lehetőséget, ha automatikusan szeretne véleményezőket hozzáadni, de nem igényel jóváhagyást a lekéréses kérelem befejezéséhez.

Kiválaszthatja , hogy a kérelmezők jóváhagyhatják-e a saját módosításaikat.

Ha minden szükséges véleményező jóváhagyja a kódot, végrehajthatja a lekéréses kérelmet.

A lekéréses kérelmek állapota azt mutatja, hogy a véleményezők jóváhagyták

Ágszabályzatok megkerülése

Bizonyos esetekben előfordulhat, hogy meg kell kerülnie a szabályzat követelményeit. A megkerülő engedélyek lehetővé teszik a módosítások leküldését közvetlenül egy ágba, vagy olyan lekéréses kérelmeket hajthat végre, amelyek nem felelnek meg az ágszabályzatoknak. Megkerülő engedélyeket adhat egy felhasználónak vagy csoportnak. Hatókörrel megkerülheti az engedélyeket egy teljes projektre, adattárra vagy egyetlen ágra.

Két engedély lehetővé teszi, hogy a felhasználók különböző módokon megkerüljék a fiókházirendet:

  • A lekéréses kérelmek végrehajtásakor a szabályzatok megkerülése csak a lekéréses kérelmek befejezésére vonatkozik. Az ezzel az engedéllyel rendelkező felhasználók akkor is végrehajthatják a lekéréses kérelmeket, ha a lekéréses kérelmek nem felelnek meg a szabályzatoknak.

  • A házirendek megkerülése a helyi tárházakból és a weben végzett módosításokból érkező leküldésekre vonatkozik. Az ezzel az engedéllyel rendelkező felhasználók közvetlenül leküldhetik a módosításokat a védett ágakra a szabályzat követelményeinek teljesítése nélkül.

Képernyőkép a szabályzatkényszerítési engedélyek megkerülésről.

Az engedélyek kezelésével kapcsolatos további információkért tekintse meg a Git-engedélyeket.

A TFS 2015–TFS 2018 2. frissítésében a szabályzatkényszerítési engedély alóli mentesség lehetővé teszi, hogy az ezzel az engedéllyel rendelkező felhasználók a következő műveleteket hajthatják végre:

  • A szabályzatok felülbírálására és lekéréses kérelem végrehajtására való bejelentkezés akkor is, ha az aktuális ágszabályzatok nem teljesülnek.
  • Leküldés közvetlenül egy ágba még akkor is, ha az adott ághoz beállított ágszabályzatok vannak beállítva. Ha egy ilyen engedéllyel rendelkező felhasználó olyan leküldést végez, amely felülírja az ágházirendet, a leküldés automatikusan átadja az ágházirendet a bejelentkezési lépés vagy figyelmeztetés nélkül.

Fontos

Körültekintően járjon el, ha lehetővé teszi a szabályzatok megkerülését, különösen az adattár és a projekt szintjén. A szabályzatok a biztonságos és megfelelő forráskódkezelés sarokkövei.

Elérésiút-szűrők

Számos ágszabályzat kínál elérésiút-szűrőket. Ha be van állítva egy elérésiút-szűrő, a szabályzat csak az elérésiút-szűrőnek megfelelő fájlokra vonatkozik. Ha üresen hagyja ezt a mezőt, az azt jelenti, hogy a szabályzat az ágban lévő összes fájlra vonatkozik.

Megadhat abszolút elérési utakat (az elérési útnak vagy helyettesítő karakterrel / kell kezdődnie) és helyettesítő karaktereket. Példák:

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

Elválasztóként több elérési utat ; is megadhat. Példa:

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

Az előtaggal ! ellátott elérési utak nem lesznek kizárva, ha egyébként belefoglalnák őket. Példa:

  • /WebApp/*;!/WebApp/Tests/* tartalmazza az összes fájlt, kivéve a /WebApp fájlokat a /WebApp/Tests
  • !/WebApp/Tests/* nem ad meg fájlokat, mivel először semmi sem szerepel a fájlban

A szűrők sorrendje jelentős. A szűrők balról jobbra vannak alkalmazva.

Kérdések és válaszok

Leküldhetem a módosításokat közvetlenül a fiókszabályzatokkal rendelkező ágakra?

A módosításokat csak akkor küldheti le közvetlenül a szükséges ágszabályzatokkal rendelkező ágakra, ha rendelkezik az ágszabályzatok megkerülésére vonatkozó engedélyekkel. Ezeknek az ágaknak a módosítása csak lekéréses kérelmeken keresztül végezhető el. Ha nem kötelező ágszabályzatokkal rendelkeznek, közvetlenül leküldheti a módosításokat az opcionális ágszabályzatokkal rendelkező ágakra.

Mi az automatikus kiegészítés?

A lekéréses kérelmek az ágszabályzatokkal konfigurált ágakba az Automatikus kiegészítés beállítása gombbal rendelkeznek. Ezt a lehetőséget választva automatikusan végrehajthatja a lekéréses kérelmet, miután az minden szabályzatot teljesített. Az automatikus kiegészítés akkor hasznos, ha nem számít a módosításokkal kapcsolatos problémákra.

Mikor vannak bejelölve a fiókszabályzat feltételei?

A fiókszabályzatok újraértékelődnek a kiszolgálón, amikor a lekéréses kérelmek tulajdonosai leküldéses módosításokat hajtanak végre, és amikor a véleményezők szavaznak. Ha egy szabályzat elindít egy buildet, a build állapota várakozási állapotot állít be, amíg a build befejeződik.

Használhatok XAML-builddefiníciókat a fiókszabályzatokban?

Nem, az XAML-builddefiníciók nem használhatók ágszabályzatokban.

Milyen helyettesítő karaktereket használhatok a szükséges kód véleményezőihez?

Az egy csillag * tetszőleges számú karakternek felel meg, beleértve az előre- és a fordított perjeleket / \is. A kérdőjelek ? egyeznek egyetlen karakterlel.

Példák:

  • *.sqla .sql kiterjesztésű összes fájlnak megfelel.
  • /ConsoleApplication/* egyezik a ConsoleApplication nevű mappában lévő összes fájllal.
  • /.gitattributes megegyezik az adattár gyökerében található.gitattributes* fájllal.
  • */.gitignore megegyezik az adattárban található . gitignore fájllal.

A szükséges kódfelügyelői útvonalak megkülönböztetik a kis- és nagybetűket?

Nem, a fiókszabályzatok nem érzékenyek a kis- és nagybetűkre.

Hogyan konfigurálhatok több felhasználót kötelező véleményezőként, de csak egy felhasználót kell jóváhagynom?

Hozzáadhatja a felhasználókat egy csoporthoz, majd véleményezőként hozzáadhatja a csoportot. A csoport bármely tagja jóváhagyhatja, hogy megfeleljen a szabályzatkövetelményeknek.

Megkerülő házirend engedélyekkel rendelkezem. Miért jelenik meg továbbra is a szabályzathibák a lekéréses kérelem állapotában?

A konfigurált szabályzatok mindig kiértékelésre kerülnek a lekéréses kérelmek módosításaihoz. A szabályzatot megkerülő engedélyekkel rendelkező felhasználók esetében a jelentett szabályzat állapota csak tanácsadás. Ha a megkerülési engedélyekkel rendelkező felhasználó jóváhagyja, a hiba állapota nem blokkolja a lekéréses kérelmek befejezését.

Miért nem tudom befejezni a saját lekéréses kéréseimet, ha a "A kérelmezők jóváhagyhatják a saját módosításaikat"?

Mind a Véleményezők minimális számának megkövetelése, mind az Automatikusan belefoglalt véleményezők házirendje lehetővé teszi a kérelmezők számára a saját módosítások jóváhagyását. Minden szabályzatban a beállítás csak az adott házirendre vonatkozik. A beállítás nincs hatással a másik szabályzatra.

A lekéréses kérelem például a következő szabályzatokkal rendelkezik:

  • A véleményezők minimális számának megkövetelése legalább egy véleményezőt igényel.
  • Az automatikusan belefoglalt véleményezők megkövetelik , hogy Ön vagy egy csapat, amelyben véleményezőként szerepel.
  • Az automatikusan belefoglalt véleményezők engedélyezik a kérelmezők számára, hogy jóváhagyják a saját módosításaikat .
  • A véleményezők minimális számának megkövetelése nem teszi lehetővé, hogy a kérelmezők jóváhagyják a saját módosításaikat .

Ebben az esetben a jóváhagyás megfelel az Automatikusan belefoglalt véleményezőknek, de nem igényel minimális számú véleményezőt, hogy ne tudja befejezni a lekéréses kérelmet.

Más szabályzatok is lehetnek, például tiltsa meg a legutóbbi leküldéses leküldéses felhasználók számára a saját módosítások jóváhagyását, amelyek megakadályozzák a saját módosítások jóváhagyását még akkor is, ha a kérelmezők jóváhagyhatják a saját módosításaikat .

Mi történik, ha az elérésiút-szűrők elérési útja nem helyettesítő karakterrel vagy helyettesítő karakterrel / kezdődik?

A nem helyettesítő karakterrel vagy helyettesítő karakterrel / kezdődő elérésiút-szűrőkben lévő elérési útnak nincs hatása, és az elérésiút-szűrő úgy értékel, mintha nem lett volna megadva az elérési út. Egy ilyen elérési út nem egyezhet meg az / abszolút fájl elérési útjával.