Einen Pull Request in Azure DevOps erstellen Sie, indem Sie einen Branch mit Ihren Änderungen nach Azure Repos pushen und daraus einen Pull Request gegen den Ziel-Branch öffnen. Anschließend ergänzen Sie die Angaben für das Review und schließen den Pull Request erst ab, wenn die Vorgaben des Ziel-Branches erfüllt sind.
Ein Pull Request ist der formale Vorschlag, Änderungen aus einem Quell-Branch in einen Ziel-Branch zu übernehmen. Er bündelt Diff, Review, Kommentare und Prüfungen an einer Stelle.
Worum es beim Erstellen praktisch geht:
- den richtigen Quell- und Ziel-Branch wählen
- den Zweck der Änderung klar benennen
- Reviewer und Work Items sauber zuordnen
- die Regeln des Ziel-Branches beachten
Dieser Beitrag behandelt Azure DevOps Services mit Azure Repos und Azure Pipelines. Azure DevOps Server bleibt hier außen vor, weil Microsoft einzelne neuere Review- und KI-Funktionen dafür nicht anbietet oder später vorsieht (Microsoft Learn, verschiedene Seiten, gelesen bzw. geprüft am 01.11.2026 und 24.10.2026).
Branch erstellen und Änderungen pushen
Starten Sie den Branch dort, wo die Änderung fachlich beschrieben ist: meist an einem Work Item. So bleibt der Bezug von Anfang an klar, und Sie vermeiden Sammel-Branches ohne eindeutigen Zweck.
Leiten Sie den Branch von dem Branch ab, in den die Änderung später voraussichtlich gehen soll. In vielen Teams ist das main, bei Releases oft ein eigener Release-Branch. Ein konsistenter Startpunkt reduziert unnötige Differenzen im späteren Vergleich.
Für den Namen des Branches reicht ein einfaches, wiedererkennbares Schema. Hilfreich sind vor allem diese Teile:
- Art der Änderung, etwa Feature, Bugfix oder Hotfix
- kurzer fachlicher oder technischer Bezug
- Kennung des Work Items oder Tickets
Arbeiten Sie die Änderung in kleinen, zusammenhängenden Commits aus und pushen Sie den Branch nach Azure Repos, sobald er für andere sichtbar sein soll. Erst dann kann das Team darauf aufbauen, etwa für gemeinsames Review oder weitere Prüfungen.
Wenn Sie den weiteren Rahmen rund um Status, Datenweg und geplante Schutzmechanismen einordnen möchten, finden Sie den aktuellen Stand auf der Seite zu Sicherheit und Daten. Geplante Anmeldung und Abomodell stehen unter Preise und Anmeldung, dokumentierte Änderungen im öffentlichen Changelog. Belastbare Ergebnisse gehören getrennt davon auf die Seite für gemessene Nachweise, die bis zu realen Läufen leer bleibt.
Pull Request öffnen: Titel, Beschreibung, Reviewer, Work Items
Öffnen Sie den Pull Request erst gegen den Branch, in den die Änderung wirklich übernommen werden soll. Davon hängen die geltenden Branch Policies ab. Der Ziel-Branch steuert also nicht nur die Richtung des Merge, sondern auch die verbindlichen Prüfungen.
Der Titel sollte die Änderung in einem Satz erkennbar machen. Die Beschreibung ergänzt nur das, was im Diff nicht zuverlässig sichtbar ist. Nützlich sind vor allem:
- fachlicher Zweck der Änderung
- betroffene Bereiche im Repository
- Annahmen oder Grenzen
- Hinweise, worauf Reviewer besonders achten sollen
Reviewer wählen Sie so, dass Fachlichkeit und Code-Verantwortung abgedeckt sind. In Azure Repos können zusätzlich automatisch eingeschlossene Reviewer greifen. Gemeint sind Personen oder Gruppen, die über eine Policy automatisch zu Pull Requests hinzugefügt werden, etwa für bestimmte Pfade oder Komponenten.
Verknüpfen Sie außerdem das passende Work Item. So bleibt der Bezug zu Anforderung, Fehler oder Aufgabe im Pull Request selbst sichtbar. Falls auf dem Ziel-Branch die Policy für verknüpfte Work Items aktiv ist, gehört dieser Schritt nicht nur zur Ordnung, sondern zu den Voraussetzungen für den Abschluss.
Microsoft nennt für Azure Repos diese Policy-Arten: Mindestanzahl an Reviewern, verknüpfte Work Items, gelöste Kommentare, erlaubte Merge-Typen, Build Validation, Status Checks und automatisch eingeschlossene Reviewer; alle sind standardmäßig deaktiviert (Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026).
Für die Praxis heißt das: Nicht der Ersteller des Pull Requests bestimmt, was genügt, sondern die Konfiguration des Ziel-Branches. Gerade bei main sollte Ihr Team diese Regeln bewusst festlegen.
Review, Votes und Kommentare sinnvoll nutzen
Ein Pull Request wird im Review nicht nur gelesen, sondern schrittweise eingeordnet. Dabei helfen Votes und Kommentar-Threads. Ein Vote ist die ausdrückliche Einschätzung eines Reviewers zum aktuellen Stand des Pull Requests.
Für die Praxis zählt vor allem: Votes beziehen sich immer auf die vorliegende Iteration. Eine Iteration ist ein neuer Stand desselben Pull Requests nach weiteren Pushes. Kommen neue Commits dazu, kann eine frühere Zustimmung fachlich überholt sein.
Darum sollten Sie im Team festlegen,
- wann nach neuen Pushes erneut geprüft wird,
- ob nur die letzte Iteration freigegeben werden muss,
- ob bestehende Zustimmungen zurückgesetzt werden sollen,
- wie mit „wait“ oder ablehnenden Votes umgegangen wird.
Diese Punkte sind in Azure-Repos-Policies abbildbar. Microsoft nennt bei der Reviewer-Policy unter anderem die Optionen, ob Ersteller eigene Änderungen genehmigen dürfen, ob die zuletzt pushende Person selbst freigeben darf und ob bei neuen Pushes mindestens eine Freigabe auf der letzten Iteration nötig ist (Microsoft Learn, „Branch policies“, gelesen am 01.11.2026).
Halten Sie Rückfragen und Entscheidungen im Pull Request selbst fest. So bleibt er die verlässliche Stelle für den Review-Kontext, statt dass Absprachen in Chat, Ticket oder Meeting verteilt sind.
Wenn Sie zusätzliche automatische Reviews nutzen, trennen Sie deren Rolle klar von formalen Freigaben. Microsoft dokumentiert für die Public Preview von Copilot code review in Azure Repos, dass diese Funktion immer nur eine Comment Review hinterlässt. Sie erfüllt damit keine Required-Reviewer-Policy und blockiert einen Merge nicht (Microsoft Learn, „Review pull requests“ und „Review pull requests with Copilot code review“, gelesen am 01.11.2026).
Pull Request abschließen: Merge-Typ, Quell-Branch löschen, Auto-Complete
Vor dem Abschluss lohnt ein letzter Blick auf die Folgen des Merge. Denn an diesem Punkt entscheiden Sie nicht mehr über den Inhalt der Änderung, sondern über ihren Eintrag in die Zielhistorie.
Der Merge-Typ regelt in Azure Repos vor allem die Form des Git-Verlaufs. Git-Verlauf meint die sichtbare Reihenfolge und Struktur der übernommenen Commits. Microsoft beschreibt diese Einstellung als History-Governance, nicht als direkte Sicherheitskontrolle (Microsoft Learn, „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026).
Für Teams sind meist diese Fragen entscheidend:
- Soll die Zielhistorie knapp und leicht lesbar bleiben?
- Muss die genaue Commit-Folge aus dem Quell-Branch erhalten bleiben?
- Soll Ihr Audit-Modell auf einzelnen Commits oder auf dem zusammengeführten Ergebnis aufbauen?
Ein Squash-Merge verdichtet den Quell-Branch zu einem Commit im Ziel-Branch. Das kann die Historie vereinfachen. Wenn Ihre Nachvollziehbarkeit jedoch auf der exakten Commit-Reihenfolge beruht, verweist Microsoft auf Merge-Commit-Strategien statt auf Squash (Microsoft Learn, „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026).
Den Quell-Branch können Sie nach dem Abschluss löschen, wenn er seinen Zweck erfüllt hat. Das hält die Branch-Liste aufgeräumt und senkt die Wahrscheinlichkeit, dass später versehentlich auf einem erledigten Branch weitergearbeitet wird.
Auto-Complete passt vor allem dann, wenn der Pull Request inhaltlich fertig ist, der Abschluss aber noch auf ausstehende Prüfungen wartet. Azure DevOps schließt ihn dann automatisch ab, sobald die Bedingungen des Ziel-Branches erfüllt sind.
Typische Entscheidungen im Team: Policies, Sicherheit, Datenfragen
In vielen Teams scheitert ein sauberer Pull-Request-Ablauf nicht am Erstellen des Pull Requests, sondern an unklaren Standards. Legen Sie deshalb für kritische Ziel-Branches ausdrücklich fest, welche Nachweise vor dem Abschluss vorliegen müssen und wer Ausnahmen überhaupt setzen darf.
Für main nennt Microsoft als sinnvolle Ausgangsbasis unter anderem:
- mindestens zwei Reviewer
- automatisch eingeschlossene Reviewer für sensible Pfade
- verknüpfte Work Items
- Build Validation
- aufgelöste Kommentare
- Bypass-Berechtigungen nur für eine kleine Admin-Gruppe
Das stammt aus Microsoft Learn, „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Wenn Sie zusätzliche KI-Funktionen rund um Pull Requests prüfen, betrachten Sie den Datenweg getrennt von der Bedienung. Für Copilot code review dokumentiert Microsoft, dass die Datenresidenz nicht an die Datenresidenzgrenzen Ihrer Azure-DevOps-Organisation gebunden ist; Verarbeitung kann also trotz EU-Hosting in einer anderen Geografie stattfinden. Quelle: Microsoft Learn, „Copilot code review FAQ“, gelesen am 01.11.2026.
Sobald dabei Quellcode, Kommentare oder Metadaten zusätzliche Dienste durchlaufen, stellt sich neben Datenschutz auch die Frage nach DORA, NIS2 und Mitbestimmung. Klären Sie das mit Ihrem Rechtsbeistand oder dem Datenschutzbeauftragten; dieser Beitrag ersetzt keine Rechtsberatung.
Häufige Fragen
Muss jeder Pull Request mit einem Work Item verknüpft sein?
Nicht zwingend. Technisch können Sie einen Pull Request auch ohne verknüpftes Work Item anlegen. Verbindlich wird die Zuordnung erst dann, wenn auf dem Ziel-Branch die Policy für verknüpfte Work Items aktiv ist. Microsoft führt „Check for linked work items“ als eigene Branch Policy; sie ist wie die anderen Policies standardmäßig deaktiviert (Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026).
Praktisch ist die Verknüpfung vor allem dann hilfreich, wenn Dritte später verstehen sollen, warum die Änderung entstanden ist.
Warum kann ich einen Pull Request sehen, aber nicht abschließen?
Dann fehlen meist noch Rechte oder verpflichtende Nachweise auf dem Ziel-Branch. In Azure Repos können unter anderem diese Regeln greifen:
- Mindestzahl an Reviewern
- Build Validation
- Status Checks
- aufgelöste Kommentare
- verknüpfte Work Items
Zusätzlich empfiehlt Microsoft für wichtige Branches, die Berechtigungen zum Umgehen von Policies nur einer kleinen Admin-Gruppe zu geben (Microsoft Learn, „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026).
Sind Branch Policies in Azure Repos standardmäßig aktiv?
Nein. Microsoft dokumentiert die Policy-Arten für Azure Repos, weist aber zugleich darauf hin, dass sie standardmäßig ausgeschaltet sind (Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026).
Für Teams heißt das: Wenn Sie verbindliche Reviews, Builds oder Status Checks erwarten, sollten Sie die Konfiguration des Ziel-Branches prüfen, statt davon auszugehen.
Lassen sich Branch Policies auch automatisiert verwalten?
Ja. Microsoft nennt dafür zwei Wege: die „az repos policy“-Befehle und die REST API (Microsoft Learn, „Branch policies“, gelesen am 01.11.2026).
Das ist vor allem für Teams nützlich, die Regeln projektübergreifend einheitlich setzen oder Änderungen an Policies nachvollziehbar verwalten möchten.
Nächster Schritt
Entscheidend ist weniger das Öffnen des Pull Requests als die Frage, was auf dem Ziel-Branch als Nachweis zählt. Prüfen Sie dafür im Team vor allem diese Punkte:
- welche Policies auf
mainund Release-Branches wirklich aktiv sind - welche Status Checks nur informieren und welche verbindlich sind
- ob Ihr Review-Modell zur Iterationslogik Ihrer Pull Requests passt
Wenn Sie Automatisierung in diesem Ablauf beobachten, trennen Sie sauber zwischen Review-Hinweisen, formalen Freigaben und dem eigentlichen Merge.
Polier von ballmüller solutions, Berlin, ist am 01.11.2026 in Entwicklung und nicht verfügbar. Vorgesehen ist für Azure DevOps Services, Work Items aus Azure Boards in Pull Requests in Azure Repos umzusetzen; die Branch Policies des Kunden gelten, und der Agent selbst merged nie.