Merge-Konflikte in Azure Repos lösen Sie direkt im Pull Request oder lokal im Git-Client. Für kleine, klare Textkonflikte reicht oft der Browser; bei mehreren Dateien, Umbenennungen oder nötigen Tests ist der lokale Weg meist passender. Danach muss der Pull Request die aktiven Branch Policies erneut erfüllen.
Ein Merge-Konflikt entsteht, wenn Git Änderungen aus Quell- und Zielbranch nicht eindeutig zusammenführen kann. Das betrifft oft dieselbe Stelle in einer Datei oder eng verbundene Änderungen.
Dieser Beitrag richtet sich an Teams mit Azure DevOps Services, Azure Repos und Azure Pipelines. Er hilft Ihnen bei der Entscheidung zwischen Browser und lokalem Vorgehen.
Wenn Sie den Ablauf um Konflikte herum im Team sauber festhalten wollen, passen dazu eine PR-Vorlage, Draft-Pull-Requests und ein Leitfaden zum Pull Request erstellen.
Warum Konflikte in Azure Repos entstehen
Konflikte entstehen, wenn Git zwei Änderungen nicht mehr eindeutig zu einer Fassung verbinden kann. In Azure Repos passiert das typischerweise, wenn Quell- und Zielbranch zwischenzeitlich an denselben Stellen oder an eng verbundenen Dateien weitergelaufen sind.
Typische Auslöser sind:
- dieselbe Datei wurde in beiden Branches bearbeitet
- eine Datei wurde umbenannt oder verschoben, während parallel Inhalt geändert wurde
- Imports, Signaturen oder Schnittstellen wurden gleichzeitig angepasst
- ein größeres Refactoring lief parallel zu Funktionsänderungen
- Formatierungsänderungen haben viele Zeilen betroffen
Ein Refactoring ist eine strukturelle Änderung am Code, ohne die beabsichtigte Fachfunktion zu ändern.
Für die Einordnung im Team ist wichtig: Ein Merge-Konflikt ist zunächst kein Hinweis auf schlechten Code. Er zeigt vor allem, dass mehrere Änderungen zeitlich und technisch aufeinandergetroffen sind. Je größer die Abweichung eines Feature-Branches von der Zielbranch, desto eher wird Git an Grenzen der automatischen Zusammenführung stoßen.
Zusätzlich prägt Ihre gewählte Merge-Strategie, wie oft Konflikte sichtbar werden und wie sie sich später nachvollziehen lassen. Die Azure-Repos-Einstellung Limit merge types steuert laut Microsoft Learn eher die Historie als eine direkte Sicherheitsfunktion. Wenn für Sie die genaue Commit-Folge wichtig ist, sollten Sie Merge-Strategien bewusst einordnen.
Im Browser lösen: Wann das ausreicht
Im Pull Request im Browser sind Sie gut aufgehoben, wenn der Konflikt klein, klar und unmittelbar lesbar ist. Das passt vor allem bei wenigen betroffenen Textdateien und dann, wenn Sie die beabsichtigte Fassung ohne zusätzlichen Projektkontext sicher festlegen können.
Praktisch ist der Browser vor allem in diesen Fällen:
- nur einzelne Konfliktstellen statt einer Kette zusammenhängender Änderungen
- keine Umbenennungen, Verschiebungen oder generierten Dateien
- keine Binärdateien
- keine Entscheidung, die erst nach lokalem Build sinnvoll prüfbar wäre
Eine Binärdatei ist eine Datei, deren Inhalt nicht sinnvoll zeilenweise als Text zusammengeführt werden kann.
Weniger passend ist der Browser, wenn Sie beim Lesen zwischen mehreren Dateien springen müssen, Seiteneffekte vermuten oder erst Tests Klarheit schaffen. Dann kostet das Auflösen im Pull Request oft mehr Konzentration als ein lokaler Abgleich.
Hilfreich ist deshalb eine einfache Teamregel: Browser nur für überschaubare Textkonflikte, alles mit technischem Risiko lokal. So vermeiden Sie, dass ein Konflikt zwar formal verschwindet, die eigentliche Entscheidung aber ungeprüft bleibt.
Für Teams, die solche Abläufe zusätzlich dokumentieren möchten, lohnt eine saubere Trennung der Themen: Fragen zu Datenschutz, Datenpfad, Identitäten und Guardrails gehören auf die Seite zu Sicherheit und Daten. Vorläufige Angaben zu Anmeldung und Abo-Modell stehen bei Preise und Anmeldung. Spätere echte Messwerte gehören in den Bereich für gemessene Ergebnisse. Änderungen an Produktstand und Funktionsumfang halten Sie am besten im öffentlichen Changelog nach.
Lokal lösen: Zielbranch mergen oder rebasen
Sobald ein Konflikt mehrere Dateien berührt oder erst mit laufendem Projektkontext verständlich wird, ist der lokale Weg meist der sauberere. Das gilt auch bei Umbenennungen, Verschiebungen und Fällen, in denen Sie die Änderung erst nach Build und Tests sicher beurteilen können.
Für das Einholen der Zielbranch haben Sie zwei Muster:
- Merge übernimmt den aktuellen Stand der Zielbranch in Ihren Arbeitsbranch.
- Rebase setzt Ihre eigenen Commits auf den neueren Stand der Zielbranch.
Der Unterschied betrifft vor allem die Commit-Historie. Eine Commit-Historie ist die nachvollziehbare Reihenfolge der Änderungen in Git. Merge erhält die bisherige Abfolge, Rebase schreibt sie für den Quellbranch neu.
Darum eignet sich Merge oft besser, wenn ein Branch bereits von mehreren Personen genutzt wird oder Commits schon geteilt sind. Rebase passt eher, wenn Sie den Branch selbst kontrollieren und eine geradlinige Abfolge Ihrer Commits pflegen möchten.
Für Azure Repos ist dabei wichtig: Welche Abschlussarten im Pull Request überhaupt zulässig sind, legt die Policy Limit merge types fest; Quelle: Microsoft Learn „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026.
Außerdem ordnet Microsoft diese Einstellung als Steuerung der Historie ein, nicht als direkte Sicherheitsfunktion. Wenn für Ihr Team die genaue Commit-Folge für Nachvollziehbarkeit oder interne Prüfpfade relevant ist, sollten Sie die Wahl von Merge oder Rebase bewusst daran ausrichten; Quelle: Microsoft Learn „Secure repositories in Azure Repos and Azure Pipelines“, gelesen am 01.11.2026.
Nach dem lokalen Lösen zählt vor dem Push vor allem dies:
- Konfliktmarker vollständig entfernen
- Ergebnis fachlich prüfen
- Build und Tests lokal ausführen
- erst dann den Branch aktualisiert pushen
Rechnen Sie danach mit einer neuen Pull-Request-Iteration. Dadurch können Freigaben zurückgesetzt, neue Freigaben auf der letzten Iteration verlangt und Pipelines oder Status Checks erneut ausgelöst werden; Quelle: Microsoft Learn „Branch policies“, gelesen am 01.11.2026.
Konflikte vermeiden: kleine Branches, häufig integrieren
Die wirksamste Vermeidung von Merge-Konflikten ist zugleich organisatorisch und technisch: Halten Sie Änderungen klein, lassen Sie Branches nicht unnötig lange offen und integrieren Sie regelmäßig mit der Zielbranch. Je kürzer die Zeit zwischen Änderung und Integration, desto kleiner ist meist die Differenz, die Git später zusammenführen muss.
In der Praxis helfen vor allem diese Muster:
- mehrere kleine Pull Requests statt eines großen Sammel-Branchs
- Refactorings getrennt von Funktionsänderungen
- Formatierungswellen, Umbenennungen und Verschiebungen bewusst abstimmen
- Änderungen an stark genutzten Dateien früh sichtbar machen
Für Teams mit Azure Pipelines lohnt sich häufige Integration besonders dann, wenn Build Validation aktiv ist. Fehler und Nebenwirkungen werden dann näher an der verursachenden Änderung sichtbar und nicht erst nach vielen weiteren Commits; Quelle: Microsoft Learn „Branch policies overview“ und „Secure repositories in Azure Repos and Azure Pipelines“, gelesen am 01.11.2026.
Hilfreich sind außerdem Entwürfe für Pull Requests. So wird eine Änderung früh im Team sichtbar, auch wenn sie noch nicht fertig ist, und der Branch läuft fachlich und technisch seltener weit von der Zielbranch weg. Ein Entwurf ist ein Pull Request, der schon diskutiert werden kann, aber noch nicht als abschließender Review-Kandidat gedacht ist.
Ebenso wichtig ist die Arbeitsorganisation. Wenn mehrere Personen an benachbarten Bereichen arbeiten, senken klare Absprachen zu Reihenfolge, Zuständigkeiten und Schnittstellen die Konfliktwahrscheinlichkeit oft stärker als jedes Tool.
Automatisch einbezogene Reviewer für sensible Pfade lösen Konflikte nicht direkt. Sie machen betroffene Stellen aber früher sichtbar und unterstützen konsistente Entscheidungen im Review; Quelle: Microsoft Learn „Secure repositories in Azure Repos and Azure Pipelines“, gelesen am 01.11.2026.
Auch automatische Code Review nimmt Ihnen Konflikte nicht ab, wenn ein Pull Request bereits im Konfliktzustand ist. Laut Microsoft prüft Copilot in Azure Repos nur aktive, konfliktfreie Pull Requests; Quelle: Microsoft Learn „Copilot code reviews“, gelesen am 01.11.2026.
Häufige Fragen zum Lösen von Merge-Konflikten
Bleibt mein Pull Request derselbe, wenn ich den Konflikt behebe?
Ja, in der Regel bleibt es derselbe Pull Request. Sie ergänzen keinen neuen Vorgang, sondern liefern eine weitere Iteration derselben Änderung. Das ist für Reviews wichtig, weil sich die Grundlage der Beurteilung geändert hat.
Praktisch bedeutet das:
- Kommentare können erneut relevant werden
- Prüfungen laufen oft noch einmal an
- Freigaben können nach Policy ihren Status ändern
Warum darf ich trotz gelöstem Konflikt oft noch nicht abschließen?
Der Konflikt ist nur ein Teil des Wegs zum Abschluss. Ob ein Pull Request abgeschlossen werden darf, entscheidet in Azure Repos über die aktiven Branch Policies.
Microsoft nennt in „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026, unter anderem diese Richtlinien:
- Mindestzahl an Reviewerinnen und Reviewern
- verknüpfte Work Items
- aufgelöste Kommentare
- Build Validation
- Status Checks
- automatisch einbezogene Reviewer
Wenn eine dieser Bedingungen nach der Konfliktlösung wieder offen ist, bleibt der Abschluss gesperrt.
Was passiert mit bestehenden Freigaben nach einem neuen Push?
Das hängt von der Reviewer-Policy ab. Laut Microsoft Learn „Branch policies“, gelesen am 01.11.2026, kann Azure Repos bei neuen Pushes Freigaben auf verschiedene Arten behandeln.
Möglich sind zum Beispiel diese Einstellungen:
- auf der letzten Iteration mindestens eine neue Freigabe verlangen
- alle Freigaben zurücksetzen
- alle Reviewer-Stimmen zurücksetzen
- den letzten Pushenden nicht als genehmigende Person zulassen
Gerade nach Konfliktlösungen sollten Sie deshalb prüfen, welche Regel Ihre Zielbranch tatsächlich verwendet.
Ist ein Konflikt ein Hinweis auf ein Problem im Repository?
Nicht automatisch. Ein Konflikt zeigt zunächst nur, dass Git zwei Änderungen nicht sicher selbst zusammenführen konnte. Das ist bei paralleler Arbeit normal.
Auffällig wird es eher dann, wenn Konflikte gehäuft an denselben Stellen auftreten, etwa bei:
- langen offenen Branches
- großen Sammeländerungen
- parallelen Refactorings
- häufig geänderten Schnittstellen
Dann lohnt sich weniger die Suche nach einem Einzelfehler als die Prüfung des Arbeitszuschnitts im Team.
Nächster Schritt
Legen Sie für Ihr Team einen festen Umgang mit Konflikten fest, statt im Einzelfall neu zu improvisieren. Entscheidend ist weniger das Werkzeug als eine klare Erwartung: Wer löst den Konflikt, wer prüft die inhaltliche Entscheidung, und wann gilt eine Änderung nach einer neuen Iteration erneut als reviewreif.
Sinnvoll sind dabei drei Punkte:
- Zuständigkeit für Konfliktlösung und fachliche Prüfung trennen
- für sensible Bereiche feste Reviewer einplanen
- nach jeder Konfliktlösung die PR erneut auf offene Kommentare, Builds und Status prüfen
Wenn Sie den Einsatz KI-gestützter Entwicklung in Azure DevOps Services später bewerten, gehört dazu auch die Frage nach Datenschutz, DORA, NIS2 und Mitbestimmung. Klären Sie das mit Ihrer Rechtsberatung oder dem Datenschutzbeauftragten. Polier ist in Entwicklung und am 01.11.2026 nicht verfügbar.