Comment resoudre les conflits de metadonnees Salesforce lors d'un merge

Pour resoudre un conflit de metadonnees Salesforce lors d'un merge, traitez le fichier comme des noeuds XML plutot que comme des lignes : ouvrez le fichier en conflit, conservez les changements independants des deux cotes, ne supprimez que l'edition vraiment en conflit, puis validez le XML et deployez vers une scratch org ou une sandbox avant de committer. La plupart des conflits Salesforce sont des faux positifs dus a l'ordre du XML, pas de vrais desaccords, donc l'objectif est de reconcilier, pas de designer un gagnant. Voici comment le faire proprement.

Qu'est-ce qu'un conflit de merge de metadonnees Salesforce ?

Un conflit de merge survient quand deux branches Git modifient le meme fichier et que Git ne peut decider quelle version gagne, alors il s'arrete et vous rend le fichier avec des marqueurs de conflit. Sur Salesforce, ce fichier est presque toujours des metadonnees declaratives stockees 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 modele.

Pourquoi les conflits de metadonnees Salesforce arrivent-ils si souvent ?

Trois proprietes des metadonnees Salesforce rendent les conflits bien plus frequents que dans du code ordinaire :

• L'ordre du XML est non deterministe. La Metadata API peut renvoyer les memes elements dans un ordre different d'une recuperation a l'autre, donc Git signale une difference la ou rien n'a change.
• De gros fichiers uniques. Les profils, permission sets et layouts entassent des centaines de reglages sans rapport dans un seul fichier, donc deux personnes editant des objets differents entrent quand meme en collision sur des lignes adjacentes.
• Git voit des lignes, pas des cles. Il ne peut pas savoir que deux editions visent des noeuds XML differents ; il voit seulement du texte qui se chevauche et leve un conflit.

Nous approfondissons les causes racines dans pourquoi les conflits de metadonnees arrivent et comment les arreter.

Comment resoudre un conflit de metadonnees lors d'un merge, etape par etape ?

1. Lisez les marqueurs. Ouvrez le fichier en conflit et trouvez <<<<<<<, ======= et >>>>>>>. Tout ce qui est au-dessus du separateur est votre branche ; tout ce qui est en dessous est la branche entrante.
2. Identifiez le type de metadonnee. Pour un profil ou une permission set, travaillez au niveau du noeud : chaque bloc <fieldPermissions> ou <objectPermissions> est une unite, pas les lignes autour.
3. Conservez les deux changements independants. Si un cote a ajoute une permission de champ et l'autre a change un objet different, gardez les deux noeuds. Celui qui a merge en premier ne devrait pas "gagner" la ligne en silence, c'est ainsi que de vraies editions se perdent.
4. Ne supprimez que le vrai conflit. Quand les deux cotes ont edite differemment exactement le meme noeud, c'est la seule decision humaine que l'outil ne peut prendre. Choisissez la bonne valeur deliberement.
5. Validez le XML. Confirmez que le fichier est bien forme et que les cles de noeuds ne sont pas dupliquees, puis retirez chaque marqueur de conflit.
6. Deployez et testez avant de committer. Poussez les metadonnees resolues 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 coequipier, voyez comment resoudre les conflits sans perdre le travail de personne.

Comment cesser de resoudre les memes conflits a la main ?

Les merges manuels ligne par ligne ne passent pas a l'echelle. La solution durable est un merge conscient des metadonnees 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 change que d'un cote et ne signalant que les vrais conflits ; nous detaillons la configuration dans comment configurer un Git merge driver conscient de Salesforce. Les plateformes DevOps poussent la meme idee plus loin : Gearset, Copado, Flosum et Blue Canvas proposent tous des fonctions de merge semantique ou intelligent qui ignorent l'ordre XML non fonctionnel et ne font remonter que les vrais conflits. Serpent applique le meme principe dans des pipelines Git-native, pour que votre equipe examine des decisions, pas du bruit. Une bonne hygiene de source aide aussi, et la gestion des metadonnees Salesforce couvre les habitudes qui previennent les conflits des le depart : branches a duree de vie courte, merges frequents, environnements synchronises, et un proprietaire unique pour les composants partages comme les profils. Parcourez toute la bibliotheque 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 change ?

Parce que la Metadata API renvoie les elements XML dans un ordre non deterministe, Git voit des lignes reordonnees comme des differences meme quand les reglages sont identiques.

Puis-je simplement choisir un cote du conflit ?

Seulement quand les deux cotes ont edite exactement le meme noeud. Si les changements touchent des noeuds differents, choisir un cote supprime en silence le vrai travail d'un coequipier.

Dois-je resoudre les conflits de profil dans le fichier de profil ?

Quand c'est possible, deplacez les permissions d'objet et de champ vers des permission sets plutot que des profils. Des fichiers plus petits et cibles entrent bien moins souvent en collision.

Ai-je besoin d'un outil special, ou Git seul suffit-il ?

Git seul convient aux petites equipes, mais un merge driver conscient des metadonnees ou une plateforme DevOps avec merge semantique enleve l'essentiel du travail manuel des que plus de quelques developpeurs partagent des metadonnees.