Salesforce-metadataconflicten oplossen tijdens een merge

Om een Salesforce-metadataconflict tijdens een merge op te lossen, behandel je het bestand als XML-nodes in plaats van regels: open het conflicterende bestand, behoud de onafhankelijke wijzigingen van beide kanten, laat alleen de echt botsende wijziging vallen, valideer daarna de XML en deploy naar een scratch org of sandbox voordat je commit. De meeste Salesforce-conflicten zijn valse positieven door XML-volgorde, geen echte meningsverschillen, dus het doel is verzoenen, niet een winnaar kiezen. Zo doe je het netjes.

Wat is een Salesforce-metadata-mergeconflict?

Een mergeconflict ontstaat wanneer twee Git-branches hetzelfde bestand wijzigen en Git niet kan beslissen welke versie wint, dus stopt het en geeft het bestand terug met conflictmarkeringen. Op Salesforce is dat bestand bijna altijd declaratieve metadata opgeslagen als XML: een profiel, permission set, flow of layout. Git vergelijkt tekst regel voor regel, en XML past niet goed in dat model.

Waarom komen Salesforce-metadataconflicten zo vaak voor?

Drie eigenschappen van Salesforce-metadata maken conflicten veel frequenter dan in gewone code:

• XML-volgorde is niet-deterministisch. De Metadata API kan dezelfde elementen in een andere volgorde teruggeven tussen ophaalacties, dus Git markeert een verschil waar niets echt veranderde.
• Grote enkele bestanden. Profielen, permission sets en layouts stoppen honderden ongerelateerde instellingen in een bestand, dus twee mensen die verschillende objecten bewerken botsen toch op aangrenzende regels.
• Git ziet regels, geen sleutels. Het kan niet zien dat twee wijzigingen verschillende XML-nodes raken; het ziet alleen overlappende tekst en meldt een conflict.

We gaan dieper op de oorzaken in waarom metadataconflicten ontstaan en hoe je ze stopt.

Hoe los je een metadataconflict tijdens een merge stap voor stap op?

1. Lees de markeringen. Open het conflicterende bestand en zoek <<<<<<<, ======= en >>>>>>>. Alles boven de scheidingslijn is jouw branch; alles eronder is de inkomende branch.
2. Identificeer het metadatatype. Voor een profiel of permission set werk je op node-niveau: elk <fieldPermissions>- of <objectPermissions>-blok is een eenheid, niet de regels eromheen.
3. Behoud beide onafhankelijke wijzigingen. Als de ene kant een veldrecht toevoegde en de andere een ander object wijzigde, behoud beide nodes. Wie eerst mergede zou niet stilletjes de regel moeten "winnen", zo raken echte wijzigingen verloren.
4. Laat alleen de echte botsing vallen. Wanneer beide kanten exact dezelfde node anders bewerkten, is dat de ene menselijke beslissing die de tool niet kan maken. Kies de juiste waarde bewust.
5. Valideer de XML. Bevestig dat het bestand welgevormd is en dat node-sleutels niet gedupliceerd zijn, verwijder daarna elke conflictmarkering.
6. Deploy en test voor het committen. Push de opgeloste metadata naar een scratch org of sandbox, draai je tests, en commit dan pas en voltooi de merge.

Voor de discipline om nooit de wijziging van een teamgenoot te verliezen, zie hoe je conflicten oplost zonder iemands werk te verliezen.

Hoe stop je met dezelfde conflicten handmatig oplossen?

Handmatige regel-voor-regel-merges schalen niet. De duurzame oplossing is een metadata-bewuste merge die XML-structuur begrijpt. Een Salesforce-bewuste Git merge driver vergelijkt bestanden node voor node, mergt automatisch alles wat maar aan een kant veranderde en markeert alleen de echte botsingen; we behandelen de setup in hoe je een Salesforce-bewuste Git merge driver opzet. DevOps-platforms voeren hetzelfde idee verder door: Gearset, Copado, Flosum en Blue Canvas leveren allemaal semantic- of smart-merge-functies die niet-functionele XML-volgorde negeren en alleen echte conflicten tonen. Serpent past hetzelfde principe toe binnen GitHub-native pijplijnen, zodat je team beslissingen beoordeelt, geen ruis. Goede source-hygiene helpt ook, en Salesforce-metadata beheren behandelt de gewoonten die conflicten in de eerste plaats voorkomen: kortlevende branches, frequente merges, omgevingen synchroon houden, en gedeelde componenten zoals profielen een enkele eigenaar geven. Bekijk de volledige SF Guides-bibliotheek voor meer, en vergelijk tooling-opties op onze prijzen-pagina.

FAQ

Waarom markeert Git conflicten als er niets echt veranderde?

Omdat de Metadata API XML-elementen in niet-deterministische volgorde teruggeeft, ziet Git herschikte regels als verschillen zelfs als de instellingen identiek zijn.

Kan ik gewoon een kant van het conflict kiezen?

Alleen wanneer beide kanten exact dezelfde node bewerkten. Als de wijzigingen verschillende nodes raken, verwijdert een kant kiezen stilletjes het echte werk van een teamgenoot.

Moet ik profielconflicten in het profielbestand oplossen?

Verplaats waar mogelijk object- en veldrechten naar permission sets in plaats van profielen. Kleinere, gerichte bestanden botsen veel minder vaak.

Heb ik een speciaal tool nodig, of is gewone Git genoeg?

Gewone Git werkt voor kleine teams, maar een metadata-bewuste merge driver of een DevOps-platform met semantic merge neemt het meeste handwerk weg zodra meer dan een paar developers metadata delen.