Branch Policies in Azure DevOps sind Regeln auf Branch-Ebene, die festlegen, unter welchen Bedingungen ein Pull Request abgeschlossen werden darf. In Azure Repos steuern sie Review-Pflichten, technische Prüfungen und Nachvollziehbarkeit vor dem Merge.
Für den Betrieb heißt das: Sie schützen nicht einfach „den Branch“, sondern definieren einen verbindlichen Prüfpfad für Änderungen in wichtige Ziel-Branches. Eine Pull Request ist dabei der vorgeschlagene Änderungsstand, der vor der Übernahme geprüft und freigegeben wird.
Nach Microsoft Learn, „Branch policies and settings“ und „About branches and branch policies“ (gelesen am 01.11.2026), sind die zentralen Richtlinien in Azure Repos zunächst deaktiviert. Sie konfigurieren sie bewusst pro Branch, zum Beispiel für:
- Mindestanzahl an Reviewern
- verknüpfte Work Items
- aufgelöste Kommentare
- Build Validation
- Status Checks
- automatisch eingeschlossene Reviewer
- zulässige Merge-Typen
Der Beitrag richtet sich an Plattform- und DevOps-Verantwortliche, die Azure DevOps Services oder Azure DevOps Server in ihrer Organisation betreiben und absichern. Unterschiede zwischen Services und Server werden nur dort genannt, wo sie für die Praxis relevant sind.
Warum Sie Branches schützen sollten
Ungeschützte Ziel-Branches machen aus Review-Regeln schnell Gewohnheitsrecht: In einem Repository wird streng geprüft, im nächsten reicht ein kurzer Blick, und im dritten wird im Zweifel direkt gepusht. Für den Betrieb ist das riskant, weil Freigabe, Nachvollziehbarkeit und technische Prüfung dann von Team zu Team unterschiedlich ausfallen.
Branch Policies ziehen hier eine klare Linie. Sie legen fest, welche Bedingungen vor dem Abschluss eines Pull Requests erfüllt sein müssen. Ein Pull Request ist der Änderungsvorschlag, der vor der Übernahme in den Ziel-Branch geprüft wird.
Der praktische Nutzen liegt vor allem in drei Punkten:
- Reviews werden nicht nur erwartet, sondern erzwungen.
- Offene Diskussionen bleiben bis zur Klärung sichtbar.
- Änderungen lassen sich sauber einem Arbeitskontext und einem Prüfschritt zuordnen.
Wichtig ist dabei die Trennung von Regel und Recht. Eine Policy definiert den Prüfpfad im Pull Request. Ob jemand trotzdem direkt pushen, Richtlinien umgehen oder einen Merge abschließen darf, steuern Berechtigungen. Für diese Seite der Absicherung ist die Einordnung zu Rechten rund um Push, Merge und Bypass relevant.
Branches zu schützen heißt daher nicht, Git restriktiv zu machen. Es heißt, für sensible Ziel-Branches einen verlässlichen Standard festzulegen.
Die wichtigsten Branch Policies im Überblick
Laut Microsoft Learn, „About branches and branch policies“ und „Branch policies and settings“ (gelesen am 01.11.2026), kennt Azure Repos diese Kernrichtlinien: Mindestanzahl an Reviewern, verknüpfte Work Items, aufgelöste Kommentare, eingeschränkte Merge-Typen, Build Validation, Status Checks und automatisch eingeschlossene Reviewer. Alle sind standardmäßig ausgeschaltet und wirken daher erst dann, wenn Sie sie bewusst pro Branch konfigurieren.
Die Richtlinie Minimum number of reviewers legt fest, wie viele zustimmende Stimmen ein Pull Request mindestens braucht, bevor er abgeschlossen werden darf. In der Praxis ist das oft der Kern Ihrer Review-Pflicht, weil sich daran entscheidet, ob Änderungen nur gelesen oder tatsächlich formal freigegeben wurden.
Zu dieser Reviewer-Richtlinie gehören mehrere Optionen, die den Ablauf deutlich verändern können:
- Antragsteller dürfen ihre eigenen Änderungen freigeben oder nicht.
- Die Person mit dem letzten Push kann von der Freigabe ausgeschlossen werden.
- Ein Abschluss trotz Stimmen wie „wait“ oder „reject“ kann erlaubt oder verhindert werden.
- Bei neuen Pushes kann verlangt werden, dass es auf der letzten Iteration erneut mindestens eine Freigabe gibt.
Eine Iteration ist der jeweils neue Stand eines Pull Requests nach weiteren Commits oder Updates.
Laut Microsoft Learn, „Branch policies and settings“ (gelesen am 01.11.2026), können Sie bei neuen Pushes außerdem Stimmen zurücksetzen lassen. Dabei lassen sich entweder alle Approvals oder allgemeiner Reviewer-Votes zurücksetzen. Auf Azure DevOps Server 2022.1 und höher gibt es zusätzlich die Möglichkeit, Freigaben auf jeder Iteration zu verlangen. Gerade bei häufig nachgebesserten Pull Requests ist das keine Kleinigkeit, sondern eine bewusste Entscheidung darüber, wie stark neue Änderungen alte Freigaben entwerten sollen.
Die Richtlinie Check for linked work items verlangt, dass ein Pull Request mit einem Arbeitselement verknüpft ist. So bleibt eine Änderung einem fachlichen oder technischen Auftrag zugeordnet. Das ist oft dann nützlich, wenn Sie Nachvollziehbarkeit nicht nur im Commit-Verlauf, sondern auch zwischen Board und Repository erwarten.
Mit Check for comment resolution stellen Sie sicher, dass offene Review-Diskussionen vor dem Abschluss bereinigt sind. Hinweise aus dem Review bleiben damit sichtbar im Prozess, statt am Ende durch einen Merge stillschweigend übergangen zu werden.
Limit merge types steuert, welche Merge-Strategien auf einem Branch zulässig sind. Wenn Sie die Unterschiede bei Pull-Request-Abläufen vertiefen möchten, finden Sie eine passende Einordnung zu Draft und Abschlusswegen bei Pull Requests.
Wichtig ist die Einordnung dieser Policy: Laut Microsoft Learn, „Secure your Git repo“ (gelesen am 01.11.2026), ist sie keine direkte Sicherheitskontrolle, sondern eher History-Governance. Squash erzeugt eine kompaktere Zielhistorie, fasst die Commits des Quell-Branches aber zu einem Commit zusammen. Wenn Ihr Audit-Modell auf der genauen Commit-Folge aufbaut, können Merge-Commit-Strategien näherliegen.
Build Validation, Status Checks und automatisch eingeschlossene Reviewer ergänzen dieses Grundgerüst. Gerade Status Checks sind oft der Punkt, an dem aus einer reinen Review-Regel ein verbindlicher Prüfpfad wird. Wie Sie solche Meldungen gezielt als Pflichtprüfung nutzen, lesen Sie im Beitrag zu Statusmeldungen als Richtlinie.
So setzen Sie für main eine sinnvolle Baseline auf
Behandeln Sie main als besonders geschützten Ziel-Branch. Für den Einstieg ist es meist sinnvoller, wenige Regeln klar und konsequent zu kombinieren, statt früh viele Sonderfälle und Ausnahmen aufzubauen.
Als praxistaugliche Baseline für main bietet sich auf Grundlage der Microsoft-Empfehlungen diese Kombination an:
- mindestens zwei Reviewer
- verknüpfte Work Items
- aufgelöste Kommentare
- Build Validation
- automatisch einbezogene Reviewer für sensible Pfade
- stark eingeschränkte Bypass-Rechte
Laut Microsoft Learn, „Secure your Git repo“ (gelesen am 01.11.2026), gehört genau dieses Set zum empfohlenen Schutz für main. Der Nutzen entsteht aus dem Zusammenspiel: Reviewer decken fachliche und technische Fragen ab, Work Items schaffen Nachvollziehbarkeit, Kommentare verhindern offene Review-Reste, Builds sichern einen technischen Mindestzustand, und automatisch einbezogene Reviewer bringen das nötige Domänenwissen an die richtigen Stellen.
Sensible Pfade sind dabei nicht nur Anwendungscode. Häufig zählen auch Infrastrukturdefinitionen, Pipeline-Dateien oder berechtigungsnahe Konfigurationen dazu.
Status Checks sind vor allem dann sinnvoll, wenn Sie neben der Build-Pipeline weitere Prüfpfade verbindlich an den Pull Request hängen wollen. Wie das als Pflichtprüfung eingebunden wird, zeigt die Vertiefung zu Statusmeldungen als verpflichtende Prüfung.
Merge-Typen sollten Sie bewusst nach Ihrem Revisions- und Audit-Modell wählen, nicht als pauschales Sicherheitsmerkmal. Prüfen Sie diese Baseline regelmäßig neu, etwa nach Änderungen an Pipelines, Teamzuschnitt oder Repository-Struktur.
Worauf Sie bei Services, Server und KI-gestützten Prüfungen achten sollten
Branch Policies selbst sind nicht der Punkt, an dem sich Services und Server stark unterscheiden. Relevant werden die Unterschiede bei angrenzenden KI-Funktionen und beim Betriebsmodell darum herum.
Für Azure DevOps Server gilt: Neuere KI-gestützte Review-Funktionen stehen dort nicht automatisch zur Verfügung. Nach Microsoft-Dokumentation war Copilot Code Review am 24.10.2026 nicht für Azure DevOps Server verfügbar; Microsoft beschreibt seine KI-Route in diesem Bereich über Azure DevOps Services. Zusätzlich sollten Sie den Produktlebenszyklus Ihrer Server-Version mitprüfen: Azure DevOps Server 2022 hat laut Microsoft Lifecycle-Dokumentation, geprüft am 24.10.2026, Mainstream Support bis 11.01.2028 und Extended Support bis 11.01.2033.
In Azure DevOps Services ist Copilot Code Review laut Microsoft Learn, „Copilot code reviews“ und „Review pull requests“ (gelesen am 01.11.2026), als Public Preview vorhanden. Für den Betrieb sind dabei vor allem drei Grenzen wichtig:
- Es prüft nur aktive Pull Requests ohne Merge-Konflikte.
- Es arbeitet nur in Repositories bis 10 GB.
- Es verarbeitet höchstens 100 geänderte Dateien und 100 Änderungen.
Wichtig für Ihre Policy-Gestaltung: Diese Reviews erscheinen als Comment Review. Sie erfüllen damit keine Required-Reviewer-Policy und erzwingen keinen Merge-Stopp.
Ein zweiter Punkt ist der Datenpfad. Laut Microsoft Learn FAQ, „Copilot code reviews FAQ“ (gelesen am 01.11.2026), folgt die Verarbeitung nicht den Datenresidenzgrenzen Ihrer Azure-DevOps-Organisation; bei EU-gehosteten Organisationen kann Verarbeitung auch in anderen Geografien stattfinden. Ob das zu Ihren Anforderungen an Datenschutz, DORA, NIS2 oder Mitbestimmung passt, sollten Sie mit Rechtsabteilung, Anwalt oder Datenschutzbeauftragten prüfen.
Häufige Fragen zu Branch Policies in Azure DevOps
Wann sind Status Checks sinnvoller als nur eine Build Validation?
Sobald neben der Pipeline noch weitere Prüfsignale verbindlich werden sollen. Build Validation deckt den Build-Pfad ab. Status Checks sind offener angelegt und eignen sich für zusätzliche Freigaben oder technische Rückmeldungen aus angebundenen Systemen.
Für die Umsetzung sind oft Service Hooks für Pull Requests oder Pull Requests per REST API der praktische Einstieg.
Was passiert mit Reviewer-Stimmen nach neuen Commits im Pull Request?
Das hängt von der gewählten Reviewer-Policy ab. In Azure Repos können Sie festlegen, ob bei neuen Pushes mindestens eine Freigabe auf der letzten Iteration nötig ist oder ob Stimmen zurückgesetzt werden. Eine Iteration ist ein neuer Stand des Pull Requests nach weiteren Commits.
Gerade bei längeren Reviews entscheidet diese Einstellung darüber, ob ältere Freigaben weiter gelten oder ob nach Änderungen neu geprüft werden muss.
Helfen Branch Policies auch bei automatisch erstellten Pull Requests?
Ja, sofern der Pull Request gegen einen geschützten Ziel-Branch läuft. Die Policy greift am Ziel-Branch, nicht an der Frage, ob ein Mensch oder ein Prozess den Pull Request angelegt hat. Für den Ablauf im Team ist dann eher wichtig, wie ein Pull Request entsteht und welche Prüfungen danach zwingend folgen.
Was ist im Alltag der häufigste Denkfehler bei „Limit merge types“?
Oft wird die Einstellung wie eine Sicherheitsmaßnahme behandelt. Tatsächlich steuern Sie damit vor allem die Form der Zielhistorie. Das ist für Revision und Nachvollziehbarkeit relevant, aber nicht dasselbe wie Review-, Kommentar- oder Build-Pflichten.
Im Betrieb wird das oft erst sichtbar, wenn Teams häufiger Merge-Konflikte lösen müssen und die gewählte Strategie den Ablauf im Pull Request beeinflusst.
Wann sollte ich meine Policy-Strategie grundsätzlich neu prüfen?
Nicht erst bei einem Vorfall. Typische Anlässe sind:
- neue Repository-Strukturen
- geänderte Zuständigkeiten
- neue Prüfautomatisierung
- ein geplanter Plattformwechsel
Gerade beim letzten Punkt hilft eine Einordnung zu Azure Repos oder GitHub, weil Branch Policies nur ein Teil der Zielarchitektur sind.
Nächster Schritt
Setzen Sie als Nächstes einen festen Betriebsstandard für geschützte Ziel-Branches auf: Zuständigkeiten, Ausnahmen, Prüfpfade und den Turnus für die Überprüfung der Einstellungen. So bleibt aus einzelnen Policies ein dauerhaft betreibbares Modell.
Gerade bei automatisierten Review- oder Änderungsschritten sollten Sie zusätzlich drei Fragen sauber trennen:
- Was ist technisch erzwungen?
- Was ist nur organisatorisch erwartet?
- Welche Punkte sollten Sie zu Datenschutz, DORA, NIS2 oder Mitbestimmung mit Rechtsabteilung, Anwalt oder Datenschutzbeauftragten prüfen?
Falls Sie den Stand von Polier verfolgen möchten: Der Dienst ist am 01.11.2026 in Entwicklung und nicht verfügbar. Den derzeit beschriebenen Stand finden Sie auf der Seite zu Sicherheit und Daten, Änderungen im öffentlichen Changelog, den vorgesehenen Weg zur Anmeldung auf der Preisseite und künftige Messwerte auf der Ergebnisseite.