In Azure DevOps können Sie einen Pull Request zunächst als Entwurf anlegen, wenn Änderungen noch nicht bereit für die reguläre Prüfung sind. Später können Sie ihn veröffentlichen, bei Bedarf abbrechen und anschließend wieder aktivieren. Für Teams mit Azure Repos und Azure Pipelines ist vor allem wichtig, wie sich dieser Status auf Review, Policies und Builds auswirkt.
Ein Pull Request ist der Antrag, Änderungen aus einem Quell-Branch in einen Ziel-Branch zu übernehmen und dabei Review sowie Branch Policies auszulösen. Dieser Beitrag beantwortet genau diese praktische Arbeitsfrage und konzentriert sich auf Azure DevOps Services mit Azure Repos. Azure DevOps Server spielt nur am Rand eine Rolle, weil mehrere neuere Funktionen dort laut Microsoft nicht oder noch nicht verfügbar sind.
Wann Sie einen Draft Pull Request öffnen sollten
Ein Draft Pull Request passt in typischen Situationen aus dem Teamalltag: Die technische Richtung ist schon erkennbar, aber die Änderung ist noch nicht reif für das reguläre Review. Sie wollen also sichtbar machen, woran Sie arbeiten, ohne schon den vollständigen Prüfprozess des Teams anzustoßen.
Praktisch ist das zum Beispiel in diesen Fällen:
- Sie möchten früh Feedback zur Architektur oder zum Lösungsweg einholen.
- Schnittstellen, Datenmodelle oder API-Grenzen sollen vorab abgestimmt werden.
- Parallele Arbeiten im Team sollen sichtbar bleiben, damit sich Änderungen nicht unnötig überlagern.
- Der spätere Review-Prozess soll vorbereitet werden, obwohl noch Punkte offen sind.
- Der Arbeitsstand soll direkt am zugehörigen Work Item nachvollziehbar bleiben.
Gerade für Tech Leads ist das nützlich, wenn Arbeit im Fluss erkennbar sein soll, Reviewerinnen und Reviewer aber noch keine formelle Prüfung übernehmen sollen. Für Entwicklerinnen und Entwickler ist der Entwurfsstatus oft dann sinnvoll, wenn bekannte Lücken noch offen sind, etwa bei Tests, beim Aufräumen der Commits oder bei einzelnen ungeklärten Kommentaren.
Wichtig ist die Abgrenzung: Ein Draft ist kein Ersatz für einen normalen Pull Request. Er ist eine Zwischenstufe vor der eigentlichen Freigabe zur Prüfung. Sobald Sie veröffentlichen, läuft der Pull Request in den üblichen Review-Fluss Ihres Teams.
In vielen Teams ist der Pull Request außerdem mit einem Work Item aus Azure Boards verknüpft. Microsoft nennt die Prüfung auf verknüpfte Work Items als mögliche Branch Policy; standardmäßig ist sie jedoch ausgeschaltet. Quelle: Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026.
Wenn Sie den Ablauf noch einmal Schritt für Schritt auffrischen möchten, finden Sie ihn im Beitrag den Grundablauf noch einmal Schritt für Schritt nachlesen.
Veröffentlichen, abbrechen, wieder aktivieren
Entscheidend ist hier weniger die Technik als die saubere Statusführung. Mit dem Veröffentlichen machen Sie aus einem sichtbaren Zwischenstand einen Pull Request, der jetzt bewusst in die reguläre Prüfung Ihres Teams geht. Ab dann sollte für alle Beteiligten klar sein: Diskussion ja, aber nicht mehr nur zur Orientierung, sondern mit Blick auf Abschlussfähigkeit.
Ein Abbruch ist sinnvoll, wenn der fachliche Bedarf entfallen ist oder der gewählte Lösungsweg nicht weiterverfolgt wird. So vermeiden Sie, dass überholte Pull Requests in Listen wie aktive Arbeit wirken. Für Tech Leads ist das vor allem dann hilfreich, wenn mehrere Themen parallel laufen und Prioritäten sich verschieben.
Wieder aktivieren können Sie denselben Pull Request, wenn genau diese Änderung weitergeführt werden soll und der bisherige Verlauf noch passt. Das lohnt sich besonders, wenn bereits Kontext vorhanden ist, zum Beispiel:
- Rückfragen zur Umsetzung
- Entscheidungen zu Schnittstellen
- Hinweise aus frühen Kommentaren
- die Verbindung zur bisherigen Diskussion
Praktisch hilft eine kurze Notiz im Pull Request, warum Sie veröffentlichen, abbrechen oder erneut öffnen. Ein knapper Satz reicht oft, damit später nachvollziehbar bleibt, ob Arbeit pausiert, verworfen oder wieder aufgenommen wurde.
Davon getrennt ist die Frage, wie am Ende gemergt wird. Der Status Draft oder veröffentlicht steuert nicht Ihre Branch-Historie. Microsoft beschreibt „Limit merge types“ als Governance für die Historie, nicht als direkte Sicherheitskontrolle. Die Einordnung dazu finden Sie im Beitrag zu Merge-Strategien in Azure Repos.
Was bei Policies und Builds in Entwürfen passiert
Für Entwürfe ist vor allem wichtig: Der Status ändert nicht die Schutzregeln des Ziel-Branches. Maßgeblich bleiben die Branch Policies, die dort konfiguriert sind.
Azure Repos kennt dafür laut Microsoft Learn unter anderem diese Policy-Arten: Mindestanzahl an Reviewerinnen und Reviewern, verknüpfte Work Items, Kommentarauflösung, Limit merge types, Build Validation, Status Checks und automatisch eingeschlossene Reviewer. Alle sind standardmäßig ausgeschaltet. Quelle: Microsoft Learn, diese Policy-Arten beschreibt „Branch policies overview“, gelesen am 01.11.2026, sowie „Branch policies“ und „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Entscheidend ist dabei der Unterschied zwischen zwei Mechanismen:
- Build Validation startet eine Build- oder Pipeline-Prüfung für den Pull Request.
- Status Checks sind Statusmeldungen am Pull Request, die als Pflichtbedingung gesetzt werden können.
Für Reviews sind die Details oft wichtiger als die reine Anzahl. Microsoft nennt bei der Reviewer-Policy unter anderem Optionen dazu, ob Ersteller ihre eigenen Änderungen genehmigen dürfen, ob die zuletzt pushende Person nicht selbst genehmigen darf und was bei neuen Pushes mit vorhandenen Freigaben geschieht. Quelle: Microsoft Learn, „Branch policies“, gelesen am 01.11.2026.
Für wichtige Branches empfiehlt Microsoft als Baseline unter anderem: Rechte zum Umgehen von Policies nur eng vergeben, mindestens zwei Reviewer verlangen, Reviewer für sensible Pfade automatisch einschließen, verknüpfte Work Items prüfen, Build Validation aktivieren und auf gelöste Kommentare bestehen. Quelle: Microsoft Learn, für wichtige Branches empfiehlt Microsoft „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Wenn Sie in Azure DevOps Services eine KI-Prüfung nutzen, sollten Sie den Status genau ansehen: Copilot Code Review ist laut Microsoft Public Preview, kann automatisch per Branch Policy starten und hinterlässt immer ein Comment review. Diese Rückmeldung erfüllt keine Required-Reviewer-Policy und blockiert keinen Merge. Preview-Funktionen haben keine SLA und können sich ändern. Quelle: Microsoft Learn, „Sprint 279 Update“, „Review pull requests“ und „Copilot code reviews“, gelesen am 01.11.2026.
Damit Reviews nicht an Formalien hängen bleiben, hilft oft schon eine klare PR-Vorlage.
Häufige Fragen
Wie unterscheiden Sie Draft, veröffentlicht und abgeschlossen im Teamprozess sinnvoll?
Nützlich ist eine einfache Trennung nach Absicht:
- Draft, wenn Sie Richtung oder offene Punkte sichtbar machen wollen
- veröffentlicht, wenn reguläres Review gewollt ist
- abgebrochen, wenn dieser Weg nicht weiterverfolgt wird
So vermeiden Sie, dass Entwürfe still zu einer zweiten Aufgabenliste werden. Ein Pull Request ist kein Ticket-Ersatz, sondern der Ort für Änderungen am Code und deren Prüfung.
Wann wird ein Entwurf organisatorisch problematisch?
Meist nicht technisch, sondern im Ablauf. Kritisch wird es, wenn niemand mehr weiß, ob der Stand nur pausiert, fachlich überholt oder noch aktiv ist. Spätestens dann lohnt sich eine kurze Einordnung im Text des Pull Requests oder ein Abbruch.
Falls in Ihrem Unternehmen Vorgaben zu Nachvollziehbarkeit, interner Kontrolle oder Aufgabentrennung gelten, betrifft das eher den gesamten Review- und Freigabeprozess als den Draft-Status selbst. Bei Fragen zu DORA, NIS2, Datenschutz oder Mitbestimmung sollten Sie das mit einer Rechtsberatung oder dem Datenschutzbeauftragten prüfen.
Welche Rolle spielt der Merge-Typ für Draft Pull Requests?
Der Entwurfsstatus beantwortet diese Frage nicht. Der Merge-Typ betrifft die Historie des Ziel-Branches. Wenn Ihr Team später Commit-Folge, Rückverfolgbarkeit oder Release-Dokumentation auswertet, sollten Sie diese Entscheidung bewusst in den Branch-Regeln treffen statt erst beim Abschluss des Pull Requests.
Können Sie aus einem Work Item direkt zu einem prüfbaren Pull Request kommen?
In Azure DevOps Services ist das als allgemeine Standardfunktion für Azure Repos aus den hier genannten Microsoft-Quellen nicht beschrieben. Genau dort liegt für viele Teams aber die praktische Lücke zwischen Board, Code, Review und Policies.
Dazu passt ein Blick auf den derzeit beschriebenen Stand in Sicherheit und Daten, auf den geplanten Bezug über Pakete und Anmeldung, auf den noch leeren Bereich Messungen und Ergebnisse sowie auf Änderungen im öffentlichen Änderungsprotokoll. Polier ist in Entwicklung und am 01.11.2026 noch nicht verfügbar.
Gewohnheiten, die Ihre PR-Liste sauber halten
Nützlich bleiben Draft Pull Requests vor allem dann, wenn Ihr Team drei Zustände sauber trennt: in Arbeit, review-bereit und verworfen. Fehlt diese Trennung, wird die PR-Liste schnell unübersichtlich, obwohl formal alles korrekt angelegt ist.
Im Alltag helfen dafür ein paar einfache Gewohnheiten:
- Öffnen Sie einen Entwurf mit erkennbarem Zweck, nicht automatisch für jede kleine Änderung. Ein Draft sollte eine konkrete Frage oder einen klaren Zwischenstand sichtbar machen.
- Formulieren Sie den Titel so, dass Status und Absicht sofort lesbar sind. Hilfreich ist zum Beispiel, ob Rückmeldung zu Design, API, Datenmodell oder Testansatz gesucht wird.
- Halten Sie die Beschreibung knapp, aber eindeutig. Offene Punkte sollten sichtbar sein, damit Reviewerinnen und Reviewer wissen, worauf sie jetzt schauen sollen und was bewusst noch unfertig ist.
- Brechen Sie nicht mehr benötigte Entwürfe konsequent ab, statt sie über Wochen offen zu lassen. Das hält Listen, Filter und Erwartungen im Team sauber.
- Prüfen Sie vor dem Veröffentlichen noch einmal den Zusammenhang: passt das verknüpfte Work Item, sind Kommentare eingeordnet, ist der Teststand nachvollziehbar und ist der richtige Ziel-Branch gewählt?
- Arbeiten Sie bei wiederkehrenden Anforderungen mit einer PR-Vorlage. Eine Vorlage ist ein vordefinierter Text für Beschreibung und Checkliste, damit wichtige Angaben nicht jedes Mal neu erfunden werden müssen.
- Pflegen Sie für sensible Branches die Policy-Konfiguration bewusst. Informelle Teamregeln helfen im Gespräch, ersetzen aber keine technische Absicherung. Microsoft weist darauf hin, dass die einzelnen Branch Policies standardmäßig deaktiviert sind. Quelle: Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026.
So bleibt ein Draft das, was er sein soll: ein klar markierter Zwischenstand und keine dauerhafte Ablage für Unentschiedenes.