KI-Konfliktloesung bei Salesforce Pull Requests: wo KI sich lohnt

Kurz gesagt: Ein Merge-Konflikt sind zwei konkurrierende Aenderungen am selben Teil einer Datei, die die Versionsverwaltung nicht allein aufloesen kann. In Salesforce sind die meisten davon nicht echt: es ist XML-Sortierrauschen, das ein metadatenbewusster Merge ohne Rueckfrage klaeren sollte. Interessant sind die Konflikte, die diesen Filter ueberleben, und genau dort verdient KI in einer Release-Pipeline zuerst ihr Geld.

Warum erzeugt Salesforce so viele Merge-Konflikte?

Zwei strukturelle Gruende, und keiner ist jemandes Schuld.

Erstens sind die Dateien riesig. Ein Profile beschreibt Berechtigungen fuer die gesamte Org, also koennen zwei Entwickler an zwei unabhaengigen Objekten benachbarte Aenderungen in einer Datei erzeugen. Profiles, Permission Sets, Page Layouts, Lightning Pages und Custom Labels sind die ueblichen Verdaechtigen.

Zweitens ist die Reihenfolge der Elemente in diesen Dateien nicht stabil. Holen Sie dasselbe Profile zweimal ab, und die Listeneintraege koennen in anderer Folge zurueckkommen. Git sieht umsortierte Zeilen und nennt das eine Aenderung, obwohl die Berechtigungen inhaltlich identisch sind. So verbringt ein Team einen Donnerstagnachmittag mit einem Konflikt, den es nicht gibt.

Was unterscheidet einen falschen von einem echten Konflikt?

Diese Unterscheidung ist der ganze Artikel, also klar gesagt.

• Falscher Konflikt. Die beiden Branches haben Verschiedenes geaendert, nur die Textdarstellung kollidiert. Zwei Entwickler haben je eine Feldberechtigung im selben Profile ergaenzt. Die richtige Antwort ist deterministisch: beide behalten.
• Echter Konflikt. Beide Branches haben dasselbe auf unterschiedliche Werte gesetzt. Einer erteilt Lesezugriff auf ein Feld, der andere entzieht ihn. Kein Algorithmus weiss, welcher richtig ist, denn die Antwort steht im Ticket, nicht im XML.

Beides als ein Problem zu behandeln ist der Grund, warum Konfliktwerkzeuge einen schlechten Ruf haben. Sie brauchen unterschiedliche Maschinerie.

Warum loest semantisches Mergen das erste und nicht das zweite?

Ein metadatenbewusster Merge parst das XML in Elemente mit stabilen Schluesseln und fuehrt Element fuer Element zusammen statt Zeile fuer Zeile. Der quelloffene Salesforce Git Merge Driver ist eine gute oeffentliche Referenz fuer diesen Ansatz: er erkennt eindeutige Schluessel in Metadatenelementen, fuehrt einzelne Eintraege statt ganzer Arrays zusammen, behandelt deterministisches Umsortieren fuer wirklich geordnete Typen wie Picklist Value Sets und Record-Type-Zuweisungen und faellt erst dann auf einen rohen Konflikt zurueck, wenn er einen Schluessel 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 gehoert deterministisch, schnell und langweilig. Richtig gemacht entfernt es die grosse Mehrheit der Salesforce-Konflikte, bevor ein Mensch sie sieht.

Was es nicht kann, ist entscheiden. Setzen beide Branches denselben Schluessel auf unterschiedliche Werte, verweigert ein korrekter deterministischer Merger, und diese Verweigerung ist richtig.

Wo verdient KI in einer Release-Pipeline wirklich ihren Platz?

Genau dort, an dieser Verweigerung. Konfliktloesung ist aus vier Gruenden eine ungewoehnlich gute erste Aufgabe fuer KI in der Auslieferung.

1. Die Aufgabe ist begrenzt. Drei bekannte Eingaben: gemeinsamer Vorfahr, unsere Version, ihre Version. Keine offene Generierung.
2. Der entscheidende Kontext ist maschinenlesbar. Ticket, PR-Beschreibung, Commit-Nachrichten und benachbarte Metadaten sagen, welche Aenderung beabsichtigt war.
3. Das Ergebnis ist pruefbar. Eine vorgeschlagene Aufloesung validiert gegen die Ziel-Org oder eben nicht. Das ist ein echter Test, kein Bauchgefuehl.
4. Es ist umkehrbar. Eine falsche Antwort faellt in der Validierung auf oder wird zurueckgerollt, anders als eine falsche Architekturentscheidung, die live geht und sich fortpflanzt.

Vergleichen Sie das damit, ein Modell Apex schreiben zu lassen: unbegrenzte Eingabe, mehrdeutiger Kontext, teure Pruefung. Konfliktloesung hat die umgekehrte Form, deshalb ist sie der vernuenftige Anfang.

Wie sieht eine sichere KI-Konfliktloesung aus?

1. Sie liest Metadatensemantik, keine Textzeilen. Bekommt das Modell Konfliktmarker, ist die Pipeline schon einen Schritt frueher gescheitert.
2. Sie zeigt Vorfahr, unsere und ihre Version nebeneinander, damit ein Reviewer die Begruendung pruefen kann und nicht nur das Ergebnis.
3. Sie nennt einen Grund und verweist auf Ticket oder Commit, das eine Seite absichtlich macht.
4. Sie validiert das zusammengefuehrte Ergebnis gegen die Ziel-Org, bevor der Merge landet, nicht danach.
5. Sie verlangt menschliche Freigabe. Immer, und besonders bei Berechtigungsmetadaten, wo ein stiller Auto-Merge den Zugriff jedes an ein Profile gebundenen Nutzers aendern kann.
6. Sie schreibt einen Audit-Trail: was vorgeschlagen wurde, was akzeptiert wurde, von wem.

Konvergiert das Oekosystem darauf?

Ja, und schnell. Salesforces eigenes DevOps Center liefert inzwischen Konfliktloesung ueber MCP-Werkzeuge, bei der grosse Sprachmodelle Konflikte analysieren, in natuerlicher Sprache erklaeren und Loesungen aus der IDE heraus vorschlagen. Wenn der Plattformanbieter LLM-Konfliktanalyse mitliefert, ist die Debatte, ob das in eine Pipeline gehoert, 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 Aufloesung aus Claude, Cursor, Windsurf oder Agentforce steuern laesst, mit Vorabpruefungen und verpflichtender menschlicher Freigabe. Das KI-Code-Review laeuft in jedem Plan, auch im kostenlosen, weil Review und Konflikt dasselbe Gespraech ueber dieselbe Aenderung sind.

FAQ

Darf KI Salesforce-Konflikte ohne Review automatisch mergen?

Nein. Vorschlagen und erklaeren, dann menschliche Freigabe verlangen, besonders bei Profiles und Permission Sets, wo ein schlechter Merge den Zugriff jedes zugewiesenen Nutzers aendert.

Macht semantisches Mergen KI ueberfluessig?

Im Gegenteil. Es entfernt die falschen Konflikte, uebrig bleiben genau die Ermessensfragen, bei denen zusaetzlicher Kontext hilft.

Warum sind Profiles die schlimmsten Faelle?

Es sind einzelne riesige Dateien fuer die ganze Org, unabhaengige 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 verknuepfte Ticket, die Commit-Nachrichten und den Zustand der Ziel-Org. Ohne die raet er selbstbewusster als ein Mensch.

Woher wissen wir, dass eine Aufloesung richtig war?

Validieren Sie das zusammengefuehrte Ergebnis gegen die Ziel-Org, bevor der Merge landet, und halten Sie fest, was vorgeschlagen und von wem freigegeben wurde.