Squash, Rebase oder Merge Commit in Azure Repos wählen Sie danach, welche Git-Historie Ihr Team später lesen und prüfen können soll. Für eine knappe Ziel-Historie passt oft Squash, für sichtbare Integrationspunkte eher Merge Commit, und Rebase ist vor allem dann sinnvoll, wenn eine lineare Historie für Ihr Team wirklich hilfreich ist.
In Azure Repos geht es bei dieser Wahl nicht um den Inhalt eines Pull Requests, sondern um seine Spur im Ziel-Branch. Eine lineare Historie zeigt Änderungen ohne Verzweigungen; damit ist schlicht eine Commit-Folge ohne sichtbare Zusammenführung gemeint.
Entscheidend sind meist drei Punkte:
- Wie gut lässt sich die Änderung später verstehen?
- Wie sichtbar soll der Integrationszeitpunkt bleiben?
- Welche Regeln gelten in Ihren Branch Policies?
Darum ist die Entscheidung selten reine Geschmackssache. In Teams mit Azure Repos und Azure Pipelines sollte die Merge-Strategie zu Review-Ablauf, Fehlersuche und Nachvollziehbarkeit passen.
Welche Merge-Typen Azure Repos beim Abschließen eines Pull Requests anbietet
Azure Repos lässt Sie die Merge-Strategie wählen, wenn ein Pull Request abgeschlossen wird. Diese Entscheidung bestimmt nicht den Inhalt der Änderung, sondern vor allem, wie die Historie im Ziel-Branch danach aussieht.
Für diesen Vergleich sind in Azure Repos drei Begriffe wichtig:
- Squash: Alle Änderungen des Pull Requests werden als ein einzelner Commit in den Ziel-Branch übernommen; die einzelnen Commits aus dem Quell-Branch sind dort anschließend nicht mehr separat sichtbar.
- Rebase: Die Commits aus dem Quell-Branch werden auf den Ziel-Branch umgelegt, sodass eine lineare Historie ohne zusätzlichen Merge Commit entstehen kann.
- Merge Commit: Die Verzweigung bleibt in der Historie erkennbar, weil ein eigener Merge Commit den Zeitpunkt der Zusammenführung markiert.
Für Teams ist das meist keine Frage von richtig oder falsch. Häufig geht es eher um eine gemeinsame Konvention: Wie soll sich die Historie lesen, wie dokumentieren Sie Releases, und wie möchten Sie bei einem Incident oder Bug später zur Integration zurückspringen?
Wichtig ist die Abgrenzung: Die Auswahl des Merge-Typs steuert die Form der Historie. Ob ein Pull Request überhaupt abgeschlossen werden darf, regeln in Azure Repos die Branch Policies.
Zu diesen Policies gehören unter anderem die Mindestanzahl an Reviewerinnen und Reviewern, verknüpfte Work Items, Kommentarauflösung, Build Validation, Status Checks, automatisch eingeschlossene Reviewer und Limit merge types. Laut Microsoft Learn in den Übersichtsseiten zu Branch Policies und den Detailseiten zu Branch Policies, jeweils gelesen am 01.11.2026, sind diese Einstellungen standardmäßig ausgeschaltet.
Wenn Sie den Pull-Request-Ablauf davor noch einmal praktisch durchgehen möchten, passt auch unser Beitrag zum Erstellen eines Pull Requests in Azure DevOps.
Was Squash, Rebase und Merge Commit jeweils mit Ihrer Historie machen
Squash verdichtet einen Pull Request zu genau einem Commit im Ziel-Branch. Das macht die Hauptlinie oft gut lesbar, besonders wenn ein Feature-Branch viele kleine Zwischenstände, Korrektur-Commits oder aufgesplittete Arbeitsschritte enthält. Für Teams, die ihre Ziel-Historie eher als Übersicht über abgeschlossene Änderungen lesen, ist das häufig angenehm.
Die Kehrseite: Die genaue Abfolge der Arbeit im Quell-Branch ist im Ziel-Branch danach nicht mehr sichtbar. Sie sehen dort vor allem das Endergebnis, nicht mehr jeden einzelnen Zwischenschritt. Microsoft beschreibt „Limit merge types“ auf der Seite zur Governance der Historie als Einstellung für die Historie, nicht als direkte Sicherheitskontrolle; gelesen am 01.11.2026. Auf derselben Seite weist Microsoft außerdem darauf hin, dass Squash die Ziel-Historie aufräumt, aber die Quell-Commits zusammenfasst. Wenn Ihr Audit-Modell von der exakten Commit-Sequenz abhängt, empfiehlt Microsoft dort Merge-Commit-Strategien statt Squash.
Rebase lässt die Historie des Ziel-Branches oft linearer wirken. Das kann für Leserinnen und Leser angenehmer sein, wenn sie Commit für Commit nachvollziehen möchten, wie eine Änderung entstanden ist. Ein Branch wird dabei so umgelegt, dass die Commits so aussehen, als wären sie direkt auf dem aktuellen Stand des Ziel-Branches entstanden.
Dazu gehört aber ein wichtiger Git-Grundsatz: Beim Rebase werden Commits neu geschrieben. Das ist nicht automatisch problematisch, sollte im Team aber verstanden sein. Gerade bei geteilten Branches kann das sonst eher Verwirrung als Klarheit erzeugen.
Merge Commit zeigt ausdrücklich, dass ein Branch in einen anderen übernommen wurde. Damit bleibt der Integrationspunkt in der Commit-Struktur sichtbar. Für Tech Leads ist das oft dann nützlich, wenn Release- oder Incident-Analysen entlang solcher Integrationspunkte laufen. Teams, die vor allem eine möglichst gerade Hauptlinie wollen, lesen dieselbe Historie oft anders.
Wenn Sie Reviews im Team stärker vereinheitlichen möchten, hilft oft auch eine klare PR-Checkliste.
Audit- und Traceability-Überlegungen: Was Sie vor der Festlegung beachten sollten
Für Audit und Traceability zählt nicht nur, wie sauber die Historie aussieht, sondern welche Kette Sie später tatsächlich nachvollziehen können. Gemeint ist die Verbindung zwischen Work Item, Pull Request, Review, Build, Status und Merge in den Ziel-Branch.
Gerade deshalb sollten Sie die Merge-Strategie nicht isoliert festlegen. Entscheidend ist, welche Informationen Ihr Team bei Rückfragen, Störungen oder Änderungen am Systemverhalten wiederfinden muss. Eine lineare Historie kann angenehm zu lesen sein. Für belastbare Nachvollziehbarkeit reichen Historienform und Commit-Struktur allein aber meist nicht aus.
Hilfreich ist vor der Festlegung eine kurze Klärung von drei Fragen:
- Muss der Integrationszeitpunkt im Ziel-Branch klar erkennbar bleiben?
- Reicht Ihnen die Zuordnung über Pull Request, Work Item und Build?
- Brauchen interne oder externe Prüfer später die genaue Commit-Folge?
Microsoft weist in „Secure Azure Repos and Git branch policies“ und „Branch policies overview“, gelesen am 01.11.2026, auf Branch Policies wie verknüpfte Work Items, Kommentarauflösung, Build Validation, Status Checks und Reviewer-Regeln hin. Diese Signale tragen häufig mehr zur Nachvollziehbarkeit bei als die Frage, ob die Historie eher kompakt oder eher integrationsorientiert aussieht.
Wichtig ist auch die Abgrenzung: „Limit merge types“ steuert die erlaubten Abschlussarten, nicht den Nachweis, dass eine Änderung fachlich geprüft oder technisch sauber validiert wurde.
Sobald DORA, NIS2, Datenschutz oder Mitbestimmung des Betriebsrats mitspielen, geht es zusätzlich um Protokolle, Aufbewahrung und mögliche Auswertbarkeit von Arbeitsabläufen. Das sollten Sie für Ihren Fall mit einer Anwältin oder einem Anwalt sowie mit der oder dem Datenschutzbeauftragten prüfen.
„Limit merge types“ als Branch Policy in Azure Repos sinnvoll einsetzen
Mit „Limit merge types“ begrenzen Sie in Azure Repos die zulässigen Abschlussarten eines Pull Requests pro Ziel-Branch. Damit legen Sie eine Teamregel für die Form der Git-Historie fest, nicht für Reviewtiefe, Testabdeckung oder Freigabequalität.
Wichtig für die Einordnung: Microsoft beschreibt diese Option in „Secure Azure Repos and Git branch policies“, gelesen am 01.11.2026, als Einstellung zur Governance der Historie und nicht als direkte Sicherheitskontrolle. Ob ein Pull Request fachlich und technisch ausreichend geprüft ist, sichern andere Branch Policies ab.
Für die Praxis heißt das: Setzen Sie „Limit merge types“ nur zusammen mit den übrigen Regeln Ihres Ziel-Branches. Welche Branch Policies Azure Repos überhaupt anbietet und dass sie standardmäßig ausgeschaltet sind, steht in „Branch policies overview“ und „Branch policies“, jeweils gelesen am 01.11.2026.
Sinnvoll ist die Policy vor allem dann, wenn Ihr Team wiederkehrend an denselben Punkten hängen bleibt:
- uneinheitliche Historie im selben Branch,
- Diskussionen erst beim Abschließen des Pull Requests,
- Ausnahmen ohne klaren Grund,
- Unsicherheit, welche Historienform für welchen Branch gelten soll.
Eine einfache Leitlinie hilft oft mehr als viele Sonderfälle: Definieren Sie je Branch, welche Historie Sie dort lesen wollen, und erlauben Sie nur die Merge-Typen, die dazu passen.
Wenn Sie solche Regeln später technisch durchsetzen oder über viele Repositories angleichen möchten, lassen sich Policies laut Microsoft Learn auch administrativ verwalten. Für die Teamentscheidung bleibt aber die wichtigere Frage: Welche Historie soll in genau diesem Branch bewusst entstehen?
Häufige Fragen zur Wahl der Merge-Strategie
Muss die Merge-Strategie in allen Projekten gleich sein?
Nein. Sinnvoll ist eine gemeinsame Grundlinie, aber nicht zwingend dieselbe Regel in jedem Repository. Ein Team mit vielen Hotfixes liest Historie oft anders als ein Team mit längeren Feature-Zweigen.
Praxistauglich ist meist eine knappe Entscheidung je Branch-Typ:
- Hauptzweig: klare, dauerhaft verständliche Historie
- Release-Zweige: erkennbare Übergänge für Wartung
- Kurzlebige Arbeitszweige: wenig Reibung im Alltag
So bleibt die Regel einfach, ohne unterschiedliche Zwecke zu vermischen.
Welche Rolle spielt die Historie bei Fehlersuche und Rollback?
Mehrere Teams unterschätzen, wie stark die spätere Arbeit davon abhängt, wie ein Merge im Ziel-Branch sichtbar bleibt. Wenn Sie bei einer Störung zuerst den Integrationspunkt suchen, hilft oft ein anderer Merge-Typ als dann, wenn Sie vor allem abgeschlossene Änderungen kompakt lesen wollen.
Für Rollback gilt außerdem: Git-Historie und fachliche Rücknahme sind nicht dasselbe. Ein sauberer Verlauf erleichtert das Verstehen, ersetzt aber keine klare Release- und Deployment-Praxis.
Ist Squash für kleine Änderungen immer die naheliegende Wahl?
Nicht zwingend. Kleine Änderungen profitieren oft von Squash, aber die Größe allein entscheidet wenig. Wichtiger ist, ob die Einzel-Commits später noch Bedeutung haben sollen, etwa für technische Analyse oder interne Nachvollziehbarkeit.
Fragen Sie deshalb eher:
- Sind die Zwischen-Commits nur Arbeitsstände?
- Soll die genaue Reihenfolge sichtbar bleiben?
- Liest Ihr Team eher Pull Requests oder Commit-Historie?
Wie oft sollte man die Teamregel zur Merge-Strategie überprüfen?
Nicht bei jeder Diskussion, aber auch nicht nie. Ein guter Zeitpunkt ist erreicht, wenn sich Arbeitsweise, Release-Modell oder Review-Ablauf merklich geändert haben. Dann lohnt eine kurze Prüfung der Konvention in Ihrer internen Dokumentation.
Was sollte man bei neuen Automatisierungen zuerst prüfen?
Prüfen Sie zuerst die Grenze zwischen Unterstützung und Entscheidung. Relevant ist, ob etwas nur Hinweise liefert oder ob Ihre bestehenden Regeln in Azure Repos weiterhin maßgeblich bleiben.
Wenn Sie Entwicklungen in diesem Feld beobachten, kann im Schlussteil auch Polier passen: Das Produkt von ballmüller solutions, Berlin, ist Stand 01.11.2026 in Entwicklung und noch nicht verfügbar.
Nächster Schritt
Treffen Sie die Entscheidung nicht im abstrakten Git-Vergleich, sondern an einem echten Ziel-Branch. Nehmen Sie einen typischen Pull Request aus Ihrem Alltag und prüfen Sie, welche Fragen Sie sechs Monate später noch beantworten möchten.
Hilfreich sind dabei vor allem diese Prüffragen:
- Soll im Branch vor allem das Ergebnis oder auch die Integration sichtbar bleiben?
- Lesen Sie die Historie eher für Ursachenanalyse, Übergaben oder Releases?
- Welche Spur muss Ihr Team bei Rückfragen tatsächlich wiederfinden?
So wird aus einer Stilfrage eine Betriebsentscheidung.
Wenn Sie Entwicklungen rund um Azure DevOps Services beobachten, kann auch Polier relevant sein: Das Produkt von ballmüller solutions, Berlin, ist Stand 01.11.2026 in Entwicklung und noch nicht verfügbar.