Conflit de merge (Git)
Un conflit de merge survient quand Git ne peut pas combiner deux branches automatiquement, parce que les deux ont modifié la même portion d'un fichier, ou que l'une a effacé un fichier modifié de son côté par l'autre. Git s'arrête, marque les versions concurrentes dans le fichier et demande à une personne de choisir le contenu final. C'est une étape normale du travail en équipe sur du code, ni une erreur ni le signe que quelque chose est cassé.
Pourquoi c’est important pour un PM
Le PM qui contribue à un dépôt, corrige des textes ou de la documentation, ou supervise un agent de code IA rencontrera des conflits. Les comprendre ôte la peur de toucher au code, et aide à organiser le travail pour qu'ils restent petits : branches de courte durée, petites pull requests et mises à jour régulières depuis la branche principale.
Exemple
Une PM corrige une faute dans le libellé d'un bouton sur sa branche, pendant qu'un développeur renomme ce même bouton sur la sienne. Quand elle met sa branche à jour, Git signale un conflit sur cette ligne. Elle garde le nouveau libellé du développeur, y applique sa correction, puis commite et pousse.
Points clés
- Les marqueurs de conflit montrent la version actuelle et la version entrante ; la résolution est le contenu que vous gardez.
- Résoudre, c'est choisir, combiner ou réécrire, puis commiter le résultat.
- Intégrer souvent la branche principale garde les conflits rares et petits.
- Lancer les tests après la résolution : une fusion sans conflit peut quand même casser un comportement.
Erreurs fréquentes
- Garder un seul côté pour tout un fichier sans lire les modifications de l'autre.
- Commiter un fichier qui contient encore des marqueurs de conflit.
- Forcer le push pour faire disparaître le problème, au risque d'écraser le travail d'un collègue.
Pour aller plus loin dans Module
Les formations et les leçons qui traitent cette notion :