
Andrew Hanna

Andrew Hanna

Kurz gesagt: Ein Merge-Konflikt sind zwei konkurrierende Änderungen am selben Teil einer Datei, die die Versionsverwaltung nicht allein auflösen kann. In Salesforce sind die meisten davon nicht echt: es ist XML-Sortierrauschen, das ein metadatenbewusster Merge ohne Rückfrage klären sollte. Interessant sind die Konflikte, die diesen Filter überleben, und genau dort verdient KI in einer Release-Pipeline zuerst ihr Geld.
Zwei strukturelle Gründe, und keiner ist jemandes Schuld.
Erstens sind die Dateien riesig. Ein Profile beschreibt Berechtigungen für die gesamte Org, also können zwei Entwickler an zwei unabhängigen Objekten benachbarte Änderungen in einer Datei erzeugen. Profiles, Permission Sets, Page Layouts, Lightning Pages und Custom Labels sind die üblichen Verdächtigen.
Zweitens ist die Reihenfolge der Elemente in diesen Dateien nicht stabil. Holen Sie dasselbe Profile zweimal ab, und die Listeneinträge können in anderer Folge zurückkommen. Git sieht umsortierte Zeilen und nennt das eine Änderung, obwohl die Berechtigungen inhaltlich identisch sind. So verbringt ein Team einen Donnerstagnachmittag mit einem Konflikt, den es nicht gibt.
Diese Unterscheidung ist der ganze Artikel, also klar gesagt.
Beides als ein Problem zu behandeln ist der Grund, warum Konfliktwerkzeuge einen schlechten Ruf haben. Sie brauchen unterschiedliche Maschinerie.
Ein metadatenbewusster Merge parst das XML in Elemente mit stabilen Schlüsseln und führt Element für Element zusammen statt Zeile für Zeile. Der quelloffene Salesforce Git Merge Driver ist eine gute öffentliche Referenz für diesen Ansatz: er erkennt eindeutige Schlüssel in Metadatenelementen, führt einzelne Einträge statt ganzer Arrays zusammen, behandelt deterministisches Umsortieren für wirklich geordnete Typen wie Picklist Value Sets und Record-Type-Zuweisungen und fällt erst dann auf einen rohen Konflikt zurück, wenn er einen Schlüssel nicht kennt. Kommerzielle Werkzeuge tun dasselbe; Gearset beschreibt genau deshalb einen metadatenbewussten semantischen Merge-Algorithmus.
Das ist keine KI und soll auch keine sein. Es ist Parsing, und Parsing gehört deterministisch, schnell und langweilig. Richtig gemacht entfernt es die große Mehrheit der Salesforce-Konflikte, bevor ein Mensch sie sieht.
Was es nicht kann, ist entscheiden. Setzen beide Branches denselben Schlüssel auf unterschiedliche Werte, verweigert ein korrekter deterministischer Merger, und diese Verweigerung ist richtig.
Genau dort, an dieser Verweigerung. Konfliktlösung ist aus vier Gründen eine ungewöhnlich gute erste Aufgabe für KI in der Auslieferung.
Vergleichen Sie das damit, ein Modell Apex schreiben zu lassen: unbegrenzte Eingabe, mehrdeutiger Kontext, teure Prüfung. Konfliktlösung hat die umgekehrte Form, deshalb ist sie der vernünftige Anfang.
Ja, und schnell. Salesforces eigenes DevOps Center liefert inzwischen Konfliktlösung über MCP-Werkzeuge, bei der große Sprachmodelle Konflikte analysieren, in natürlicher Sprache erklären und Lösungen aus der IDE heraus vorschlagen. Wenn der Plattformanbieter LLM-Konfliktanalyse mitliefert, ist die Debatte, ob das in eine Pipeline gehört, beendet.
Serpent kommt aus derselben Richtung. Es ist der einzige native
MCP-Server im Salesforce DevOps, mit resolve_metadata_conflict neben
plan_deploy, create_pull_request und
trigger_pipeline, sodass sich dieselbe Auflösung aus Claude, Cursor,
Windsurf oder Agentforce steuern lässt, mit Vorabprüfungen und verpflichtender
menschlicher Freigabe. Das KI-Code-Review läuft in jedem Plan, auch im kostenlosen,
weil Review und Konflikt dasselbe Gespräch über dieselbe Änderung sind.
Darf KI Salesforce-Konflikte ohne Review automatisch mergen?
Nein. Vorschlagen und erklären, dann menschliche Freigabe verlangen, besonders bei Profiles und Permission Sets, wo ein schlechter Merge den Zugriff jedes zugewiesenen Nutzers ändert.
Macht semantisches Mergen KI überflüssig?
Im Gegenteil. Es entfernt die falschen Konflikte, übrig bleiben genau die Ermessensfragen, bei denen zusätzlicher Kontext hilft.
Warum sind Profiles die schlimmsten Fälle?
Es sind einzelne riesige Dateien für die ganze Org, unabhängige Arbeit landet also in benachbarten Zeilen, und ihre Listenreihenfolge ist zwischen Abrufen nicht garantiert stabil.
Welchen Kontext braucht ein KI-Resolver?
Den Drei-Wege-Diff, das verknüpfte Ticket, die Commit-Nachrichten und den Zustand der Ziel-Org. Ohne die rät er selbstbewusster als ein Mensch.
Woher wissen wir, dass eine Auflösung richtig war?
Validieren Sie das zusammengeführte Ergebnis gegen die Ziel-Org, bevor der Merge landet, und halten Sie fest, was vorgeschlagen und von wem freigegeben wurde.
Unverbindlich.