Reviewer-Stimmen bei Pushes zurücksetzen können Sie in Azure Repos über die Reviewer-Richtlinie der Branch Policies in Azure DevOps. Für neue Pushes stehen je nach Einstellung drei Richtungen bereit: Stimmen weiter gelten lassen, mindestens eine Zustimmung an die letzte Iteration binden oder Stimmen zurücksetzen.
Eine Iteration ist der Stand eines Pull Requests nach einem neuen Push auf den Quell-Branch. Gemeint ist also jeweils die neueste Fassung der vorgeschlagenen Änderungen.
Dieser Beitrag behandelt Azure Repos in Azure DevOps. Für Azure DevOps Services sind die Optionen in Microsoft Learn dokumentiert; bei Azure DevOps Server hängt der genaue Umfang von der Version ab. Quellen: Microsoft Learn, „Branch policies“ und „Branch policies overview“, gelesen am 01.11.2026.
Warum Zustimmungen veralten können
Eine Zustimmung gilt fachlich immer für einen bestimmten Stand des Pull Requests. Kommt danach ein neuer Push auf den Quell-Branch, kann sich genau dieser Stand verändert haben. Dann ist nicht mehr sicher, dass die frühere Freigabe noch dieselbe Aussagekraft hat.
Das betrifft nicht nur große Umbauten. Schon kleine Änderungen können eine erneute Sicht sinnvoll machen, etwa:
- umgesetzte Review-Hinweise,
- ein nachgereichter Fix,
- neu hinzugekommene Commits,
- Änderungen durch das Auflösen von Merge-Konflikten.
Für Schutz-Branches ist das eine Governance-Frage: Wer hat welche Fassung gesehen, und welcher Stand wurde tatsächlich freigegeben? Gerade wenn mehrere Rollen beteiligt sind, sollten ältere Votes nach einem Push nicht automatisch als unverändert belastbar gelten.
Hinzu kommt der Kontext der übrigen Branch Policies. Nach Microsoft Learn gehören dazu unter anderem Mindestanzahl von Reviewern, verknüpfte Work Items, Kommentarauflösung, erlaubte Merge-Typen, Build Validation, Status Checks und automatisch einbezogene Reviewer; alle sind standardmäßig ausgeschaltet. Quellen: Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026.
Für sensible Pfade können auch automatisch einbezogene Reviewer wichtig sein. Microsoft empfiehlt für main außerdem unter anderem mindestens zwei Reviewer, Build Validation, Kommentarauflösung, verknüpfte Work Items und eine enge Vergabe von Policy-Bypass-Berechtigungen. Quelle: Microsoft Learn, „Secure Azure Repos pull requests“, gelesen am 01.11.2026.
Die Optionen bei neuen Pushes
Maßgeblich ist die Reviewer-Richtlinie des Ziel-Branches. Dort legen Sie fest, was nach einem weiteren Push auf den Quell-Branch mit vorhandenen Votes passiert.
Microsoft dokumentiert dafür in „Branch policies“ und „Branch policies overview“ drei relevante Verhaltensweisen für neue Pushes, gelesen am 01.11.2026:
- „Require at least one approval on the last iteration“
- „Reset all approval votes“
- „Reset all code reviewer votes“
Der Unterschied ist sachlich klar.
„Require at least one approval on the last iteration“ belässt den bisherigen Vote-Verlauf im Pull Request, fordert für den neuesten Stand aber mindestens eine frische Zustimmung. Die Historie bleibt also lesbar, ohne dass ältere Freigaben allein für den aktuellen Stand genügen.
„Reset all approval votes“ setzt bei einem neuen Push die positiven Freigaben zurück. Frühere Approvals zählen dann nicht mehr für die aktualisierte Fassung.
„Reset all code reviewer votes“ greift weiter. Hier werden die Reviewer-Votes insgesamt zurückgesetzt. Wenn Sie einen Push als klaren Neustart der formalen Bewertung behandeln wollen, ist das die strengere Variante.
Für den Betrieb hilft eine einfache Einordnung:
- letzte Iteration: neuer Blick auf den aktuellen Stand, bisherige Votes bleiben sichtbar
- Approval-Reset: positive Freigaben müssen nach einem Push neu erteilt werden
- vollständiger Vote-Reset: der Review-Status wird insgesamt weitergehend zurückgenommen
Diese Einstellung steuert nur den Umgang mit Votes nach neuen Pushes. Sie ersetzt weder Fragen zu Push-, Merge- und Bypass-Rechten noch Regeln für ungelöste Diskussionen; dafür ist die Policy zur Kommentarauflösung bei offenen Threads zuständig.
Wichtig für Azure DevOps Server: Die genaue Auswahl hängt von der Version ab. Microsoft dokumentiert „Require at least one approval on the last iteration“ für Azure DevOps Server 2022.1 und höher; dort gibt es zusätzlich eine Variante „on every iteration“. Quellen: Microsoft Learn, „Branch policies“ und „Branch policies overview“, gelesen am 01.11.2026.
Zustimmung auf der letzten Iteration
Diese Option ist vor allem dann nützlich, wenn Sie nach einem Push eine erneute Bestätigung für den aktuellen Stand verlangen, ohne den bisherigen Review-Verlauf unlesbar zu machen. Sie verschiebt den Fokus auf die neueste Fassung des Pull Requests, statt jede frühere Beteiligung formal zu entwerten.
Geeignet ist das vor allem in Situationen wie diesen:
- nach einem kleinen Fix auf Basis von Review-Kommentaren,
- nach einer Anpassung, die den Build wieder grün macht,
- nach redaktionellen oder strukturellen Änderungen,
- wenn der Pull Request bewusst in mehreren kleinen Schritten nachgeschärft wird.
Für die Steuerung ist wichtig, was die Option gerade nicht leistet: Sie erzwingt keine erneute Prüfung durch alle bereits beteiligten Personen. Wenn bei bestimmten Dateien oder Verzeichnissen immer dieselbe Fachrolle noch einmal draufsehen soll, brauchen Sie dafür eher passend gesetzte automatisch einbezogene Reviewer. Quelle: Microsoft Learn, „Secure Azure Repos pull requests“, gelesen am 01.11.2026.
Ebenso bleibt die Frage offener Diskussionen davon unberührt. Nicht erledigte Threads werden durch diese Einstellung nicht automatisch aus dem Weg geräumt. Im Alltag hilft hier oft eine knappe PR-Vorlage mit Checkliste, damit vor dem Abschluss noch einmal sichtbar ist, was wirklich abgearbeitet sein muss.
Kurz gesagt: Die Option ist sinnvoll, wenn Sie einen frischen Blick auf die letzte Iteration verlangen, aber nicht jeden neuen Push wie einen vollständigen Neustart des Reviews behandeln wollen.
Auswirkungen auf den Arbeitsablauf
Die Einstellung zu neuen Pushes wirkt vor allem auf Ihre Freigabekette. Entscheidend ist weniger der einzelne Pull Request als die Frage, wann ein Branch nach einer Änderung wieder als ausreichend geprüft gilt.
Für den Betrieb sind dabei meist drei Punkte wichtig:
- Wer nach einem Push überhaupt noch wirksam zustimmen darf,
- welche Prüfungen neben Reviews noch erfolgreich sein müssen,
- und ob Ihr Team eher kleine Nachbesserungen oder längere PR-Serien erwartet.
Gerade in Plattform-Teams lohnt sich deshalb der Blick auf die Policy-Reihenfolge. Wenn nach einem Push erneut ein menschliches Approval nötig ist, Build Validation aber noch läuft oder ein Status Check noch aussteht, verschiebt sich der Abschluss eines PRs organisatorisch oft an das Ende aller technischen Prüfungen. Ein Status Check ist ein externer Prüfstatus, den Azure Repos wie eine weitere Pflichtbedingung für den Abschluss auswerten kann. Quelle: Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026.
Unabhängig davon bleibt der Merge-Typ eine eigene Entscheidung. Microsoft ordnet „Limit merge types“ als Steuerung der Historie ein, nicht als direkten Sicherheitsmechanismus. Wenn Ihre Nachvollziehbarkeit auf der genauen Commit-Folge beruht, sollten Sie die Wahl des Merge-Verfahrens bewusst prüfen; der Überblick zu Merge-Typen und Historie kann dabei helfen. Quellen: Microsoft Learn, „Branch policies overview“ und „Sprint 279 Update“, gelesen am 01.11.2026.
Auch die Betriebsrichtung Ihrer Plattform spielt hinein. Microsoft beschreibt mit Enterprise Live Migrations einen Weg, Repositories in eine andere Git-Plattform zu verschieben, während Boards und Pipelines weiter genutzt werden können. Für Architektur- und Standardisierungsfragen ist daher oft nicht nur die einzelne Reviewer-Option relevant, sondern die längerfristige Rolle von Azure Repos; dazu passt der Beitrag zu Entscheidungskriterien für die Plattformwahl. Quelle: Microsoft Learn, „Sprint 279 Update“, gelesen am 01.11.2026.
Häufige Fragen aus dem Betrieb
Reicht für sensible Branches die letzte Iteration, oder sollten Votes vollständig zurückgesetzt werden?
Das hängt vor allem davon ab, wie Sie einen neuen Push fachlich bewerten. Wenn Nachbesserungen meist klein bleiben und der Review-Verlauf sichtbar bleiben soll, reicht oft die Bindung an die letzte Iteration. Wenn ein Push den Inhalt spürbar verschiebt, ist ein vollständiger Reset meist die klarere Regel.
Hilfreich ist eine einfache Unterscheidung:
- kleine Korrektur nach Review,
- zusätzlicher Commit mit neuem Risiko,
- Konfliktauflösung mit verändertem Code,
- Änderung in Bereichen mit enger Freigabekette.
Je stärker ein Push die Bewertungsgrundlage verändert, desto eher passt ein strengeres Zurücksetzen der Stimmen.
Gilt das auf Azure DevOps Server genauso wie in Azure DevOps Services?
Nicht automatisch. Microsoft dokumentiert die Optionen für Azure DevOps Services in Learn; bei Azure DevOps Server hängt der genaue Umfang von der Version ab. Für den Betrieb heißt das: Übernehmen Sie eine Policy nicht ungeprüft zwischen Services und Server.
Prüfen Sie vor einer Vereinheitlichung insbesondere:
- welche Option Ihre Server-Version tatsächlich anbietet,
- ob Ihre Teams dieselben Review-Abläufe brauchen,
- ob Dokumentation und Screenshots zur eingesetzten Version passen.
Gerade in gemischten Landschaften vermeidet das Missverständnisse bei Freigaben kurz vor dem Abschluss.
Ersetzen automatische Prüfungen die Frage nach alten Reviewer-Stimmen?
Nein. Technische Prüfungen und Reviewer-Votes beantworten unterschiedliche Fragen. Ein Build kann erfolgreich sein, obwohl nach einem neuen Push niemand den aktuellen Stand erneut fachlich angesehen hat. Umgekehrt ersetzt eine frische Zustimmung keine Build Validation oder keinen Status Check.
Für die Praxis ist deshalb meist die Kombination entscheidend:
- menschliche Freigabe für den aktuellen Stand,
- technische Pflichtprüfungen,
- enge Vergabe von Ausnahmen beim Umgehen von Policies.
Wenn Sie solche Regeln zusätzlich unter Datenschutz-, DORA-, NIS2- oder Mitbestimmungsaspekten bewerten, sollten Sie das mit einer Rechtsberatung oder Ihrer beziehungsweise Ihrem Datenschutzbeauftragten prüfen.
Wo sehen wir den Stand geplanter Funktionen, ohne daraus Verfügbarkeit abzuleiten?
Wenn das für Ihre Plattformplanung relevant ist: Im öffentlichen Changelog steht der Entwicklungsstand. Was zu Sicherheit und Daten heute gilt und was noch nicht, beschreibt die Seite zu Sicherheit und Daten. Wie Anmeldung und Pakete vorgesehen sind, steht bei den vorläufigen Paketen und der Anmeldung. Ob bereits reale Messwerte vorliegen, sehen Sie auf der Seite zu gemessenen Ergebnissen.
Nächster Schritt
Setzen Sie die Option nicht isoliert, sondern als Teil Ihrer Freigabelogik. Relevant ist, ob ein neuer Push in Ihrem Haus eher als Nachtrag oder als neuer Prüfstand gilt.
Für die Entscheidung helfen vier Leitfragen:
- Welche Folgen hätte eine veraltete Zustimmung auf diesem Branch?
- Wie stark ändern sich Pull Requests typischerweise nach dem ersten Review?
- Müssen bestimmte Rollen den neuesten Stand erneut sehen?
- Wie klar ist für Teams dokumentiert, wann ein Vote nach einem Push noch zählen soll?
Sinnvoll ist außerdem ein kurzer Praxistest mit typischen PR-Mustern aus Ihrem Betrieb.
Falls Ihre Planung auch künftige Agenten für Azure DevOps Services umfasst: Polier ist am 01.11.2026 in Entwicklung und noch nicht verfügbar.