In Azure Repos entscheiden, wer pushen, Pull Requests abschließen und Regeln umgehen darf, nicht eine einzelne Rolle, sondern die Kombination aus Sicherheitsgruppen, Repository- und Branch-Berechtigungen sowie Branch Policies. Direktes Pushen auf geschützte Branches und insbesondere Bypass-Rechte sollten deshalb nur wenige Administrationskonten erhalten; der normale Weg zum Zusammenführen läuft über Pull Requests innerhalb der gesetzten Regeln.
Eine Branch Policy ist eine serverseitig erzwungene Regel für Pull Requests. Microsoft nennt in Azure Repos als verfügbare Richtlinien Mindestzahl an Reviewern, verknüpfte Work Items, Kommentarauflösung, Merge-Typen, Build-Validierung, Status Checks und automatisch einbezogene Reviewer; alle sind standardmäßig ausgeschaltet (Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026).
Für die Praxis heißt das: Prüfen Sie Rechte und Policies immer gemeinsam. Erst diese Kombination zeigt belastbar, wer auf einem Branch tatsächlich schreiben, einen Pull Request abschließen oder Schutzregeln technisch aushebeln kann.
Sicherheitsgruppen und die Berechtigungen, die in Repositories und Branches zählen
Für die Praxis reicht der Blick auf Projektebene nicht aus. Entscheidend ist die Kombination aus Rechten auf Projekt-, Repository- und Branch-Ebene. Erst dort sehen Sie, wer tatsächlich schreiben, einen Pull Request abschließen oder auf einem Schutz-Branch Ausnahmen nutzen darf.
Vergeben Sie solche Rechte nach Möglichkeit über Sicherheitsgruppen statt direkt an Einzelpersonen. Das ist im Betrieb besser nachvollziehbar, einfacher zu pflegen und bei personellen Wechseln weniger fehleranfällig. Gerade bei geschützten Branches hilft eine kleine, klar benannte Gruppenstruktur mehr als viele individuelle Sonderfälle.
Für diesen Artikel ist eine Unterscheidung zentral:
- in einen Branch pushen
- einen Pull Request abschließen
- Branch Policies umgehen
Das sind getrennte Fähigkeiten und sollten auch getrennt geprüft werden. Wer Code in einen Branch schreiben darf, muss noch lange keinen Pull Request gegen denselben Branch abschließen dürfen. Und wer einen Pull Request abschließen darf, sollte nicht automatisch die Rechte haben, Policies zu umgehen.
Wichtig ist dabei die Branch-Ebene. Selbst wenn auf Repository-Ebene breitere Rechte bestehen, können Sie für einzelne Schutz-Branches engere Regeln setzen. Genau dort trennen viele Organisationen den Alltag von den Ausnahmen: Feature-Branches bleiben beweglicher, während Haupt- und Release-Branches knapper berechtigt werden. Typische Kandidaten sind etwa main, master oder release/*, aber das ist eher gängige Praxis als starre Vorgabe.
Microsoft empfiehlt in seiner Sicherheitsbaseline für main, die Berechtigungen „Bypass policies when completing pull requests“ und „Bypass policies when pushing“ auf eine kleine Admin-Gruppe zu beschränken, mindestens zwei Reviewer zu verlangen, Reviewer für sensible Pfade automatisch einzubeziehen, verknüpfte Work Items zu prüfen, Build-Validierung zu ergänzen und Kommentarauflösung zu verlangen (Microsoft Learn, „Secure Azure Repos by using branch policies“, gelesen am 01.11.2026).
Als Branch Policies stehen in Azure Repos Mindestzahl an Reviewern, verknüpfte Work Items, aufgelöste Kommentare, Begrenzung der Merge-Typen, Build-Validierung, Status Checks und automatisch einbezogene Reviewer zur Verfügung; alle sind standardmäßig ausgeschaltet (Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026).
Die Bypass-Berechtigungen – und warum sie selten bleiben sollten
Bei Bypass-Rechten geht es nicht um Komfort, sondern um Ausnahmen vom vorgesehenen Prüfpfad. Relevant sind zwei Berechtigungen: „Bypass policies when completing pull requests“ und „Bypass policies when pushing“. Die erste erlaubt das Abschließen eines Pull Requests trotz nicht erfüllter Policies, die zweite das direkte Schreiben auf den geschützten Branch. Microsoft empfiehlt für main, beide Rechte auf eine kleine Admin-Gruppe zu beschränken (Microsoft Learn, „Secure Azure Repos by using branch policies“, gelesen am 01.11.2026).
Praktisch entscheidend sind die Feineinstellungen der Reviewer-Policy. Laut Microsoft Learn („Branch policies“, gelesen am 01.11.2026) sollten Sie vor allem diese Punkte bewusst setzen:
- dürfen Antragstellende ihre eigenen Änderungen genehmigen,
- darf die zuletzt pushende Person selbst freigeben,
- muss nach neuen Pushes mindestens eine Zustimmung auf der letzten Iteration vorliegen,
- werden Zustimmungen oder alle Reviewer-Stimmen bei neuen Pushes zurückgesetzt.
Eine Iteration ist der Stand eines Pull Requests nach einem weiteren Push. Gerade diese Optionen entscheiden oft darüber, ob ein Review nach Änderungen noch belastbar ist oder nur formal weiterläuft.
Für ungeklärte Arbeit ist ein offen gekennzeichneter Pull Request meist der sauberere Weg als ein dauerhaft großzügig verteiltes Ausnahme-Recht.
Getrennt davon sollten Sie „Limit merge types“ einordnen. Diese Policy steuert laut Microsoft primär die Historie und ist kein unmittelbares Sicherheitskontrollinstrument (Microsoft Learn, „Secure Azure Repos by using branch policies“, gelesen am 01.11.2026). Ob Sie dafür eher Squash, Rebase oder Merge Commit zulassen, ist vor allem eine Frage der Nachvollziehbarkeit Ihrer Commit-Historie; dazu passt unser Überblick zu Merge-Strategien in Azure Repos.
Branch-Berechtigungen versus Policies: Was wofür gedacht ist
Branch-Berechtigungen und Policies greifen an verschiedenen Stellen. Berechtigungen steuern den Zugang zu Git-Aktionen. Policies steuern den Ablauf eines Pull Requests auf dem Ziel-Branch. Für den Betrieb bedeutet das: Policies prüfen den vorgesehenen Weg, aber nicht jede andere Schreibmöglichkeit daneben.
Für zusätzliche technische Prüfungen sind Status Checks der passende Baustein. Ein Status Check ist eine maschinelle Rückmeldung an einen Pull Request, die Sie als Pflichtbedingung setzen können. Damit lassen sich interne oder angebundene Prüfschritte in den Merge-Ablauf einhängen, ohne Required-Reviewer-Regeln umzudeuten.
Wichtig ist die Abgrenzung zu der derzeitigen KI-Review in Azure Repos. Microsoft schreibt, dass Copilot-Code-Review immer ein Comment Review hinterlässt. Es erfüllt daher keine Required-Reviewer-Policy und blockiert das Abschließen nicht (Microsoft Learn, „Review pull requests“ und „Copilot code reviews“, gelesen am 01.11.2026).
Außerdem gilt laut Microsoft derzeit ein enger technischer Rahmen:
- nur aktive Pull Requests ohne Merge-Konflikte; für den Umgang damit siehe Merge-Konflikte in Azure Repos lösen
- Repository-Größe bis 10 GB
- bis 100 geänderte Dateien und 100 Änderungen; zur Einordnung passt Wie groß darf ein Pull Request sein?
- Limits für gleichzeitige Reviews pro Pull Request, Organisation und Benutzer
Hinzu kommt: Die Funktion ist Public Preview. Laut Microsoft Learn („Sprint 279 Update“ und „Copilot code reviews“, gelesen am 01.11.2026) kann sie sich ändern, und Preview-Funktionen haben keine SLA. Für Schutz-Branches ist das kein Detail, sondern Teil der Betriebsbewertung.
Wenn Sie den Einsatz solcher Prüfungen strategisch einordnen, hilft oft zuerst der Blick auf Entscheidungskriterien zwischen Azure Repos und GitHub.
Service-Identitäten und Automatisierung sauber abgrenzen
Technische Identitäten sollten Sie getrennt von menschlichen Konten behandeln. Für den Schutz von Branches ist nicht nur wichtig, was ein Konto tun kann, sondern auch wofür es vorgesehen ist. Ein Build-Dienst, ein Bot und ein Administrationskonto sollten deshalb nicht dieselben Rechte tragen.
Sinnvoll ist eine knappe Rollenlogik:
- Konten, die Änderungen auf Arbeits-Branches schreiben
- Konten, die Pull Requests anlegen oder aktualisieren
- Konten, die nur Prüfergebnisse als Status an einen Pull Request melden
- wenige Konten für echte Ausnahmen
Gerade der letzte Punkt sollte eng bleiben. Wer automatisiert arbeitet, braucht oft keinen direkten Schreibzugriff auf geschützte Ziel-Branches und kein Recht, Policies zu umgehen. Für viele Abläufe reicht es, Commits außerhalb des Schutz-Branches zu erzeugen und den weiteren Weg über den Pull Request laufen zu lassen.
Bei angebundener Prüfung ist vor allem die Status-Identität relevant. Ein Status Check ist eine maschinelle Rückmeldung an den Pull Request, die Sie per Policy zur Pflicht machen können. So binden Sie Automatisierung kontrolliert ein, ohne Required-Reviewer-Regeln umzudeuten. Die technische Identität meldet dann ein Ergebnis, sie ersetzt aber keine personelle Freigabe.
Wenn Sie einen Dienst mit Codezugriff bewerten, gehört die Frage nach Verarbeitung, Rollen und Grenzen von Anfang an dazu. Bei einem geplanten Angebot wie Polier gilt dafür laut öffentlichem Änderungsstand: Stand 01.11.2026 in Entwicklung und nicht verfügbar; pro Kunde ist eine eigene Instanz in Germany West Central vorgesehen, mit eigener Datenbank, Storage, Key Vault, Service Bus und Container Apps environment; der Agent soll nie selbst mergen. Angaben zu Abo, Kontingenten und Anmeldung stehen auf der Seite zu vorläufigen Paketen. Messwerte gibt es noch nicht; die dafür vorgesehene Seite ist derzeit leer. Für Datenschutz, DORA, NIS2 und Mitbestimmung sollten Sie die konkrete Ausgestaltung mit Rechtsabteilung, Datenschutzbeauftragten oder Anwalt prüfen.
Häufige Fragen, wenn Sie Azure Repos absichern
Welche Reviewer-Einstellungen entscheiden darüber, ob ein Pull Request nach neuen Pushes noch tragfähig geprüft ist?
Oft nicht die Mindestzahl allein, sondern die Details der Reviewer-Policy. Relevant sind vor allem diese Optionen aus Microsoft Learn „Branch policies“ (gelesen am 01.11.2026):
- ob Anfragende ihre eigenen Änderungen genehmigen dürfen
- ob die zuletzt pushende Person selbst freigeben darf
- ob nach neuen Pushes eine Zustimmung auf der letzten Iteration erforderlich ist
- ob Zustimmungen oder alle Reviewer-Stimmen zurückgesetzt werden
Eine Iteration ist der Stand eines Pull Requests nach einem weiteren Push. Gerade auf Schutz-Branches prägen diese Schalter, ob ein Review nach Änderungen inhaltlich neu abgesichert wird oder nur formal bestehen bleibt.
Ist „Limit merge types“ eine Sicherheitsmaßnahme?
Nicht unmittelbar. Microsoft ordnet „Limit merge types“ in „Secure Azure Repos by using branch policies“ als Steuerung der Historie ein, nicht als direkten Sicherheitsmechanismus (gelesen am 01.11.2026).
Für die Praxis heißt das: Die Einstellung ist wichtig für Nachvollziehbarkeit, Audit-Modell und Commit-Historie, aber sie ersetzt weder Reviewer, noch Build-Validierung, noch Status Checks.
Lässt sich eine KI-Prüfung per Policy automatisch auslösen?
Ja, in Azure DevOps Services kann die derzeitige Code-Review-Funktion laut Microsoft per Branch Policy automatisch angestoßen werden; außerdem lässt sie sich auf Organisations-, Projekt- oder Repository-Ebene aktivieren und mit eigenen Anweisungen versehen (Microsoft Learn, „Sprint 279 Update“ und „Copilot code reviews“, gelesen am 01.11.2026).
Für den Betrieb sollten Sie die Grenzen mitbewerten:
- Public Preview ohne SLA
- nur aktive Pull Requests ohne Merge-Konflikte
- Repositorys bis 10 GB
- bis 100 geänderte Dateien und 100 Änderungen
- begrenzte gleichzeitige Reviews pro Pull Request, Organisation und Benutzer
Welche Daten- und Rechtsfragen sollte ich vor aktivierter KI-Review klären?
Microsoft weist in der FAQ zu Code Reviews darauf hin, dass die Datenresidenz dieser Funktion nicht an die Datenresidenzgrenzen Ihrer Azure-DevOps-Organisation gebunden ist; Verarbeitung kann also auch bei einer in der EU gehosteten Organisation in einer anderen Geografie stattfinden, etwa in den Vereinigten Staaten (Microsoft Learn, „Copilot code reviews FAQ“, gelesen am 01.11.2026).
Prüfen Sie solche Punkte vorab mit Datenschutzbeauftragten oder Anwalt. Das gilt ebenso für DORA, NIS2 und Mitbestimmung.
Nächster Schritt
Legen Sie für Schutz-Branches einen kurzen Kontrollrhythmus fest, statt Rechte nur einmal zu setzen. Relevant ist nicht nur die Konfiguration selbst, sondern auch, ob sie nach Umorganisationen, Tool-Anbindungen oder Teamwechseln noch zu Ihrem Freigabemodell passt.
Praktisch hilfreich ist eine kleine Prüfliste:
- Welche Branches gelten als besonders schutzbedürftig?
- Welche Ausnahmen sind bewusst vorgesehen?
- Welche Einstellungen sollen überall gleich sein, welche je Repository abweichen?
- Wer überprüft Änderungen an diesem Modell regelmäßig?
Wenn Sie den Einsatz eines Coding-Agenten in diesem Umfeld einordnen, beachten Sie den Reifestand genau: Polier von ballmüller solutions ist am 01.11.2026 in Entwicklung und nicht verfügbar. Geplant ist für Azure DevOps Services, aus einem Azure-Boards-Work-Item einen Pull Request in Azure Repos zu erzeugen; die Branch Policies des Kunden sollen gelten, und der Agent selbst merged nie.