Résoudre les conflits et comprendre rebase

1. Pourquoi un conflit apparaît

Git compare des versions et leur base commune pour réunir les changements. Il peut fusionner automatiquement des modifications indépendantes. Lorsque plusieurs changements touchent de manière incompatible le même contenu, ou lorsqu’une suppression entre en concurrence avec une modification, une décision humaine peut être nécessaire.

Un conflit ne signifie pas que l’historique a disparu. L’opération est suspendue et Git demande de produire une version cohérente. Le bon résultat peut reprendre un côté, combiner les deux ou réécrire la phrase : il faut comprendre l’intention métier, pas seulement retirer les marques.

2. Créer un conflit reproductible

Partez d’un dépôt propre avec au moins un commit sur main. Le fichier tarif.txt sera créé uniquement pour l’exercice.

git switch main
Set-Content -Encoding utf8 tarif.txt "Assistance : 50000 FCFA"
git add tarif.txt
git commit -m "Définir le tarif de référence"
git switch -c feature/tarif
Set-Content -Encoding utf8 tarif.txt "Assistance : 60000 FCFA"
git add tarif.txt
git commit -m "Proposer le nouveau tarif"
git switch main
Set-Content -Encoding utf8 tarif.txt "Assistance : 55000 FCFA"
git add tarif.txt
git commit -m "Actualiser le tarif principal"
git merge feature/tarif

Les deux branches ont modifié la même ligne à partir du même contenu. La fusion doit normalement signaler un conflit dans tarif.txt. Lisez status avant de continuer.

3. Lire les marques et terminer la fusion

<<<<<<< HEAD
Assistance : 55000 FCFA
=======
Assistance : 60000 FCFA
>>>>>>> feature/tarif

Dans cette fusion, la première partie correspond à la version de la branche courante, la seconde à la branche fusionnée. Les noms « ours » et « theirs » demandent davantage de prudence pendant un rebase, car le contexte de rejeu change leur lecture. Les contenus et le scénario sont plus fiables qu’une règle mémorisée sans contexte.

Supposons que l’équipe valide 60 000 FCFA avec la mention « assistance standard ». Remplacez l’ensemble du bloc par la phrase décidée, puis préparez la résolution.

Set-Content -Encoding utf8 tarif.txt "Assistance standard : 60000 FCFA"
git add tarif.txt
git diff --cached
git commit -m "Réunir les évolutions du tarif"
git status

Relisez les autres fichiers concernés et vérifiez le résultat. Pour revenir à la situation précédant une fusion encore en cours, git merge --abort est la commande adaptée. Partir d’un état propre facilite cette récupération ; un travail préexistant compliqué peut empêcher sa reconstitution complète.

4. Comprendre le rebase avant de l’utiliser

Un rebase rejoue des commits sur une autre base. Les changements peuvent être similaires, mais les commits rejoués ont de nouveaux parents et généralement de nouveaux identifiants. La branche est réécrite ; ce n’est pas une fusion qui conserve les mêmes commits sous un autre dessin.

On utilise ici rebase pour une branche de travail privée, avant partage. Réécrire des commits sur lesquels des collègues travaillent les oblige à réconcilier leurs références. Sur une branche partagée, préférez la stratégie convenue avec l’équipe.

git switch ma-branche-privee
git rebase main

Le nom ma-branche-privee désigne une branche d’entraînement existante. Si un conflit survient, corrigez les fichiers, exécutez add sur les résolutions, puis git rebase --continue. Pour abandonner le rebase en cours, utilisez git rebase --abort. On ne crée pas un commit de fusion pour terminer un rebase.

5. Inspecter une divergence distante

Quand un envoi est refusé parce que le distant contient du travail supplémentaire, commencez par récupérer et regarder le graphe. Un rejet non-fast-forward n’est pas une invitation à forcer.

git fetch origin
git log --oneline --graph --decorate --all
git log --oneline HEAD..origin/main
git log --oneline origin/main..HEAD

Les deux dernières commandes montrent respectivement les commits accessibles seulement depuis la référence distante, puis ceux accessibles seulement depuis votre branche courante, dans la comparaison choisie. Ensuite, vous pourrez intégrer les changements par une fusion ou un rebase adapté à votre situation.

--force-with-lease contrôle une attente sur la référence distante avant une réécriture forcée ; il ne rend pas toute réécriture inoffensive. Le parcours courant n’en a pas besoin. Sur main partagé, appliquez les règles du dépôt et préservez le travail des autres.

6. Résolution : la vérification compte plus que le clic

Un éditeur peut proposer « accepter la version courante » ou « accepter les deux ». Ces boutons manipulent du texte ; ils ne garantissent ni la syntaxe ni le résultat métier. Une liste HTML peut rester invalide après la disparition des marques de conflit.

1. Identifier l’opération en cours avec status.
2. Lire les intentions et les commits concernés.
3. Écrire le résultat attendu, puis vérifier les fichiers.
4. Préparer les résolutions et relire le diff.
5. Terminer avec la commande propre à merge ou à rebase.
6. Contrôler le graphe et le comportement final.

Exercices corrigés