Ja: Offene Threads blockieren den Merge in Azure Repos, wenn für den Ziel-Branch die Policy „Check for comment resolution“ aktiv ist. Ohne diese Regel bleiben offene Diskussionen sichtbar, sperren das Abschließen des Pull Requests aber nicht automatisch.
Ein Thread ist die zusammengehörige Diskussion zu einer Code-Stelle oder zum Pull Request insgesamt. Für Teams mit Azure DevOps Services ist vor allem wichtig, dass diese Sperre branchbezogen wirkt und zu den Branch Policies in Azure DevOps gehört, nicht zu Builds, Reviewer-Stimmen oder Merge-Typen.
In diesem Beitrag geht es um drei Punkte:
- wann offene Threads wirklich blockieren,
- was in Azure Repos als aufgelöst gilt,
- und welche Teamregeln dabei im Alltag helfen.
Grundlage sind die Microsoft-Learn-Seiten „Branch policies overview“, „Branch policies“ und „Securely use Git pull requests and branch policies to protect your important branches“, jeweils gelesen am 01.11.2026.
Was die Policy tatsächlich prüft
„Check for comment resolution“ ist in Azure Repos eine eigene Branch Policy. Wie die anderen Richtlinien ist sie nicht automatisch aktiv, sondern zunächst ausgeschaltet. Das geht aus Microsoft Learn auf den Seiten „Branch policies overview“ und „Branch policies“ hervor, gelesen am 01.11.2026.
Wichtig ist die Abgrenzung: Diese Policy bewertet nicht, ob der Code gut ist, ob Tests ausreichend sind oder ob genug Personen zugestimmt haben. Sie prüft einen engeren Punkt: ob Kommentar-Threads vor dem Abschluss des Pull Requests als aufgelöst markiert sind. Ein Pull Request ist der Vorschlag, Änderungen aus einem Branch in einen anderen zu übernehmen.
Für die Praxis heißt das: Sobald für den Ziel-Branch diese Policy gilt, reicht schon ein noch offener relevanter Thread, damit der Pull Request nicht abgeschlossen werden kann. Grüne Builds oder vorhandene Approvals ändern daran für sich genommen nichts.
Daneben bleiben andere Regeln getrennt bestehen. Laut Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026, sind unter anderem dies eigene Policies:
- Mindestanzahl an Reviewerinnen und Reviewern
- verknüpfte Work Items
- Build Validation
- Status Checks
- Merge-Typen
- automatisch einbezogene Reviewer
Gerade auf wichtigen Branches ist das nützlich, weil offene Review-Punkte nicht einfach untergehen, nur weil formale Freigaben schon vorliegen. Microsoft nennt in „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026, für main als Sicherheitsbaseline unter anderem mindestens zwei Reviewer, automatisch einbezogene Reviewer für sensible Pfade, verknüpfte Work Items, Build Validation und Kommentarauflösung.
Konfigurieren lassen sich solche Policies in Azure DevOps über die Oberfläche; Microsoft nennt in „Branch policies“, gelesen am 01.11.2026, außerdem „az repos policy“ und die REST API. Wenn Sie die Rechte rund um Abschließen, Pushen und Umgehen von Regeln getrennt betrachten möchten, hilft der Beitrag zur Rechtefrage in Azure Repos.
Pflicht oder optional: Wann offene Threads wirklich sperren
Entscheidend ist der Ziel-Branch. Offene Threads blockieren den Merge nur dann, wenn dort die Policy „Check for comment resolution“ aktiv ist. Fehlt diese Policy, bleiben offene Diskussionen zwar im Pull Request sichtbar, sind aber zunächst nur ein Review-Hinweis und keine automatische Merge-Sperre.
Das ist in Azure Repos bewusst branchbezogen aufgebaut. Teams können auf main oder einem Release-Branch strengere Regeln setzen und auf kurzlebigen Feature-Branches weniger strenge Vorgaben verwenden, wenn das zur eigenen Arbeitsweise passt. Branch Policies sind damit kein globaler Schalter für das ganze Repository, sondern Regeln für bestimmte Ziel-Branches.
Wichtig ist außerdem die Trennung der Mechanismen im Pull Request:
- Reviewer-Stimmen sind eine eigene Regelachse.
- Status Checks sind externe Statussignale aus angebundenen Prüfungen.
- Die Auflösung von Threads ist davon getrennt.
Daraus folgt eine häufige, aber falsche Annahme: Ein erfolgreicher Build schließt keinen offenen Thread. Ebenso ersetzt eine erreichte Mindestzahl an Reviewer-Zustimmungen nicht die Kommentarauflösung. Jede dieser Regeln muss für sich erfüllt sein, wenn sie für den Ziel-Branch aktiv ist.
Daneben gibt es noch die Berechtigungsfrage. Wer Policies beim Abschließen oder Pushen umgehen darf, wird getrennt über Rechte gesteuert. Microsoft empfiehlt in „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026, diese Rechte auf eine kleine Admin-Gruppe zu beschränken. Das schafft im Alltag Klarheit: Wer einen Pull Request abschließen will, sieht schneller, ob noch echte Diskussionspunkte offen sind oder nur formale Freigaben fehlen.
Wie aufgelöste und offene Threads praktisch funktionieren
Ein aufgelöster Thread bedeutet in Azure Repos vor allem: Die Diskussion ist beendet. Daraus folgt nicht automatisch, dass der Punkt technisch oder fachlich richtig gelöst wurde. Der Status beschreibt den Gesprächszustand, nicht die Güte der Änderung.
Für Reviews ist deshalb die Begründung wichtiger als der Klick auf „Resolved“. Ein Thread ist meist dann sauber abgeschlossen, wenn aus dem Verlauf erkennbar ist, was entschieden wurde:
- Code wurde angepasst,
- ein Hinweis wurde nach Prüfung verworfen,
- oder eine Rückfrage wurde nachvollziehbar beantwortet.
Relevant wird das vor allem nach neuen Commits im selben Pull Request. Eine Iteration ist eine neue Fassung des Pull Requests nach weiterem Push. Dabei kann ein bereits geschlossener Diskussionspunkt fachlich wieder offen wirken, obwohl sein Thread formal aufgelöst bleibt. Prüfen Sie deshalb bei einer neuen Iteration nicht nur offene Threads, sondern auch kurz, ob ältere Entscheidungen noch zum aktuellen Stand passen.
Davon getrennt laufen die Reviewer-Regeln. Microsoft beschreibt in „Branch policies“, gelesen am 01.11.2026, Optionen wie „Require at least one approval on the last iteration“, „Reset all approval votes“ und „Reset all code reviewer votes“. Diese Einstellungen betreffen Stimmen, nicht den Zustand eines Threads.
Wenn zusätzlich automatische Reviews im Spiel sind, lohnt sich dieselbe Trennung. Laut Microsoft Learn, „Review pull requests“ und „Copilot code reviews“, gelesen am 01.11.2026, hinterlässt Copilot Code Review immer ein Comment Review. Ob daraus ein Merge-Hindernis wird, hängt erst an der Policy zur Kommentarauflösung.
Bei Konflikten sollten Sie zuerst die technische Zusammenführung klären. Für KI-gestützte Abläufe sind außerdem Datenpfad, Identitäten und Guardrails getrennt vom Review-Status zu prüfen.
Teamgewohnheiten, mit denen die Policy im Alltag trägt
Nützlich wird die Policy erst dann, wenn Ihr Team den Status eines Threads gleich versteht. Legen Sie deshalb knapp fest, wer einen Punkt auf „Resolved“ setzt und in welchen Fällen das erst nach einer Rückmeldung der kommentierenden Person passieren soll. So vermeiden Sie Diskussionen über den Status statt über den Inhalt.
Praktisch ist eine kleine Arbeitsregel für Kommentare:
- eine klare Beobachtung,
- eine konkrete Stelle,
- und die erwartete Klärung.
Das hält Threads kurz und macht später sichtbar, ob wirklich noch etwas offen ist oder nur eine lose Anmerkung im Raum steht.
Ebenso hilfreich ist ein fester Schlusscheck direkt vor dem Abschließen des Pull Requests: erst offene Threads, dann Stimmen, dann Build- und Statussignale. Die Reihenfolge ist banal, verhindert aber, dass ein grüner Build psychologisch mehr Gewicht bekommt als eine fachlich offene Rückfrage.
Für Bereiche mit höherem Abstimmungsbedarf lohnt sich oft eine andere Teamregel: Nicht jede Person kommentiert alles, sondern zuständige Reviewer prüfen bestimmte Pfade verbindlich. Das passt gut zu automatisch einbezogenen Reviewerinnen und Reviewern für sensible Bereiche. Die Frage nach Squash, Rebase oder Merge Commit sollten Sie davon getrennt behandeln, denn sie betrifft vor allem die Historie; die Einordnung dazu finden Sie im Beitrag zur Wahl des Merge-Typs.
Und noch ein Alltagsdetail: Schließen Sie Threads nicht gesammelt am Ende „der Ordnung halber“. Wenn ein Punkt geklärt ist, markieren Sie ihn dann. Das hält den Review-Verlauf lesbar und reduziert Missverständnisse in längeren Pull Requests.
Häufige Fragen
Kann ein Pull Request trotz offener Threads abgeschlossen werden?
Ja, aber nur wenn für den Ziel-Branch nicht die Policy „Check for comment resolution“ gilt oder wenn berechtigte Personen Policies umgehen dürfen. Microsoft empfiehlt für wichtige Branches, die Rechte „Bypass policies when completing pull requests“ und „Bypass policies when pushing“ auf eine kleine Admin-Gruppe zu beschränken; Grundlage ist Microsofts Sicherheitsbaseline für wichtige Branches, gelesen am 01.11.2026.
Für den Review-Alltag ist die Frage daher nicht nur technisch, sondern auch organisatorisch:
- Gilt die Policy auf dem Ziel-Branch?
- Wer darf Ausnahmen auslösen?
- Ist im Team klar, wann das überhaupt akzeptabel ist?
Zählen gelöste Threads nach weiteren Commits automatisch wieder als offen?
Nein. Ein neuer Push macht einen bereits als „Resolved“ markierten Thread nicht von selbst wieder offen. Gerade deshalb lohnt nach einer neuen Iteration ein kurzer Blick auf ältere Entscheidungen. Microsoft beschreibt auf der Seite zu Branch Policies und Iterationen, gelesen am 01.11.2026, nur für Reviewer-Votes spezielle Regeln wie „Require at least one approval on the last iteration“ oder das Zurücksetzen von Stimmen.
Für Threads heißt das praktisch: Der Status bleibt, auch wenn sich der Kontext geändert hat.
Ist Copilot Code Review hier ein Ersatz für Pflicht-Reviewer?
Nein. Nach Microsoft Learn hinterlässt Copilot Code Review immer ein Comment Review und erfüllt damit keine Required-Reviewer-Policy. Das steht auf der Seite zum Review von Pull Requests, gelesen am 01.11.2026.
Wichtig ist außerdem der Betriebsstatus: Copilot Code Review war laut Dokumentation zu Copilot-Code-Reviews, gelesen am 01.11.2026, in Public Preview. Preview-Funktionen haben kein SLA und können sich ändern. Wenn Sie solche Änderungen intern sauber nachhalten wollen, hilft ein öffentlicher Änderungsverlauf.
Was sollten Sie bei Aussagen zu KI-gestützten Reviews oder Coding-Agenten nüchtern prüfen?
Sinnvoll sind vor allem drei Punkte:
- Entwicklungsstand
- gemessene Nachweise aus echten Läufen
- Daten- und Betriebsmodell
Ohne reale Runs, Kundenbetrieb oder veröffentlichte Messungen sollten Sie keine Wirkung unterstellen. Für nachvollziehbare Einordnung gehören Ergebnisse auf eine Seite mit messbaren Nachweisen, nicht in Vermutungen. Wenn es um einen Dienst in Entwicklung geht, sollten außerdem Anmeldemodus und Status klar getrennt vom Funktionsversprechen stehen; dafür ist eine Seite zu Paketlogik und Anmeldung der richtige Ort.
Nächster Schritt
Setzen Sie für Ihren Ziel-Branch einen kurzen Praxischeck an.
- Welche offenen Threads tauchen in den letzten Pull Requests wiederholt auf?
- Sind das echte ungeklärte Punkte oder eher lose Hinweise ohne klare Erwartung?
- Wer entscheidet im Zweifel sichtbar über „Resolved“ oder „Active“?
Damit prüfen Sie nicht nur die Einstellung in Azure Repos, sondern die tatsächliche Review-Disziplin Ihres Teams.
Hilfreich ist außerdem ein gemeinsamer Blick auf Sonderfälle: Architekturhinweise, Sicherheitsfragen, spätere Nacharbeiten und bewusst akzeptierte Abweichungen sollten im Thread klar als Entscheidung erkennbar sein. Sonst bleibt vor dem Merge unnötig Interpretationsspielraum.
Falls Sie den Einsatz KI-gestützter Abläufe in Azure DevOps Services bewerten, trennen Sie sauber zwischen Review-Kommentaren, verbindlichen Policies und automatisierten Statussignalen. Polier von ballmüller solutions ist in Entwicklung und noch nicht verfügbar; vorgesehen ist, aus einem Azure Boards Work Item einen Pull Request in Azure Repos zu erzeugen, wobei die Branch Policies des Kunden gelten und der Agent selbst nie merged.