Résoudre les conflits de fusion d’une pull request GitHub

Le simple affichage de marqueurs ne suffit pas à connaître la logique métier impactée.

1. Relever les fichiers conflictuels affichés par GitHub.
2. Consulter les échanges de revue et l’origine des modifications.
3. Identifier les responsables des deux changements.

git fetch origin
git status --short
git log --oneline --graph --all -12

Résoudre le conflit localement facilite l’inspection des diffs et l’exécution des tests.

1. Se placer sur la branche source de la pull request.
2. Récupérer main depuis le dépôt distant.
3. Fusionner main dans la branche de recette, sans modifier main.

git switch feature/ma-pr
git fetch origin
git merge origin/main
git status --short

La résolution correcte peut nécessiter une combinaison des deux changements.

1. Ouvrir chaque fichier contenant les marqueurs <<<<<<<, ======= et >>>>>>>.
2. Comparer les deux versions et écrire une version cohérente.
3. Demander l’avis de l’auteur du changement si la règle métier n’est pas évidente.

git diff --name-only --diff-filter=U
git diff --check
# Corriger les fichiers dans l’éditeur avant git add.

Les contrôles doivent porter sur la version combinée.

1. Relire le diff et exécuter les tests propres au projet.
2. Ajouter uniquement les fichiers résolus.
3. Terminer le commit de fusion une fois les changements contrôlés.

git diff --check
git status --short
git add chemin/du-fichier
git commit

La vérification de CI et la revue doivent suivre la nouvelle tête de branche.

1. Pousser normalement la branche source de la PR.
2. Vérifier la disparition du signal de conflit dans GitHub.
3. Relancer ou examiner la CI et les approbations nécessaires avant fusion.

git push origin feature/ma-pr
# Dans GitHub : vérifier Files changed et Checks.