Comment résoudre les conflits de métadonnées Salesforce lors d'un merge

Pour résoudre un conflit de métadonnées Salesforce lors d'un merge, traitez le fichier comme des noeuds XML plutôt que comme des lignes : ouvrez le fichier en conflit, conservez les changements indépendants des deux côtés, ne supprimez que l'édition vraiment en conflit, puis validez le XML et déployez vers une scratch org ou une sandbox avant de committer. La plupart des conflits Salesforce sont des faux positifs dus à l'ordre du XML, pas de vrais désaccords, donc l'objectif est de réconcilier, pas de désigner un gagnant. Voici comment le faire proprement.

Qu'est-ce qu'un conflit de merge de métadonnées Salesforce ?

Un conflit de merge survient quand deux branches Git modifient le même fichier et que Git ne peut décider quelle version gagne, alors il s'arrête et vous rend le fichier avec des marqueurs de conflit. Sur Salesforce, ce fichier est presque toujours des métadonnées déclaratives stockées en XML : un profil, une permission set, un flow ou un layout. Git compare le texte ligne par ligne, et le XML ne s'accorde pas bien avec ce modèle.

Pourquoi les conflits de métadonnées Salesforce arrivent-ils si souvent ?

Trois propriétés des métadonnées Salesforce rendent les conflits bien plus fréquents que dans du code ordinaire :

• L'ordre du XML est non déterministe. La Metadata API peut renvoyer les mêmes éléments dans un ordre différent d'une récupération à l'autre, donc Git signale une différence là où rien n'a changé.
• De gros fichiers uniques. Les profils, permission sets et layouts entassent des centaines de réglages sans rapport dans un seul fichier, donc deux personnes éditant des objets différents entrent quand même en collision sur des lignes adjacentes.
• Git voit des lignes, pas des clés. Il ne peut pas savoir que deux éditions visent des noeuds XML différents ; il voit seulement du texte qui se chevauche et lève un conflit.

Nous approfondissons les causes racines dans pourquoi les conflits de métadonnées arrivent et comment les arrêter.

Comment résoudre un conflit de métadonnées lors d'un merge, étape par étape ?

1. Lisez les marqueurs. Ouvrez le fichier en conflit et trouvez <<<<<<<, ======= et >>>>>>>. Tout ce qui est au-dessus du séparateur est votre branche ; tout ce qui est en dessous est la branche entrante.
2. Identifiez le type de métadonnée. Pour un profil ou une permission set, travaillez au niveau du noeud : chaque bloc <fieldPermissions> ou <objectPermissions> est une unité, pas les lignes autour.
3. Conservez les deux changements indépendants. Si un côté a ajouté une permission de champ et l'autre a changé un objet différent, gardez les deux noeuds. Celui qui a mergé en premier ne devrait pas "gagner" la ligne en silence, c'est ainsi que de vraies éditions se perdent.
4. Ne supprimez que le vrai conflit. Quand les deux côtés ont édité différemment exactement le même noeud, c'est la seule décision humaine que l'outil ne peut prendre. Choisissez la bonne valeur délibérément.
5. Validez le XML. Confirmez que le fichier est bien formé et que les clés de noeuds ne sont pas dupliquées, puis retirez chaque marqueur de conflit.
6. Déployez et testez avant de committer. Poussez les métadonnées résolues vers une scratch org ou une sandbox, lancez vos tests, et seulement ensuite committez et terminez le merge.

Pour la discipline de ne jamais perdre le changement d'un coéquipier, voyez comment résoudre les conflits sans perdre le travail de personne.

Comment cesser de résoudre les mêmes conflits à la main ?

Les merges manuels ligne par ligne ne passent pas à l'échelle. La solution durable est un merge conscient des métadonnées qui comprend la structure XML. Un Git merge driver conscient de Salesforce compare les fichiers noeud par noeud, fusionnant automatiquement tout ce qui n'a changé que d'un côté et ne signalant que les vrais conflits ; nous détaillons la configuration dans comment configurer un Git merge driver conscient de Salesforce. Les plateformes DevOps poussent la même idée plus loin : Gearset, Copado, Flosum et Blue Canvas proposent tous des fonctions de merge sémantique ou intelligent qui ignorent l'ordre XML non fonctionnel et ne font remonter que les vrais conflits. Serpent applique le même principe dans des pipelines Git-native, pour que votre équipe examine des décisions, pas du bruit. Son résolveur de conflits par IA règle les cas courants et ne remonte que ce qui exige une décision humaine. Une bonne hygiène de source aide aussi, et la gestion des métadonnées Salesforce couvre les habitudes qui préviennent les conflits dès le départ : branches à durée de vie courte, merges fréquents, environnements synchronisés, et un propriétaire unique pour les composants partagés comme les profils. Parcourez toute la bibliothèque SF Guides pour en savoir plus, et comparez les options d'outillage sur notre page tarifs.

FAQ

Pourquoi Git signale-t-il des conflits quand rien n'a vraiment changé ?

Parce que la Metadata API renvoie les éléments XML dans un ordre non déterministe, Git voit des lignes réordonnées comme des différences même quand les réglages sont identiques.

Puis-je simplement choisir un côté du conflit ?

Seulement quand les deux côtés ont édité exactement le même noeud. Si les changements touchent des noeuds différents, choisir un côté supprime en silence le vrai travail d'un coéquipier.

Dois-je résoudre les conflits de profil dans le fichier de profil ?

Quand c'est possible, déplacez les permissions d'objet et de champ vers des permission sets plutôt que des profils. Des fichiers plus petits et ciblés entrent bien moins souvent en collision.

Ai-je besoin d'un outil spécial, ou Git seul suffit-il ?

Git seul convient aux petites équipes, mais un merge driver conscient des métadonnées ou une plateforme DevOps avec merge sémantique enlève l'essentiel du travail manuel dès que plus de quelques développeurs partagent des métadonnées.