Git
[GIT] Merge Request avec rebase et conflits
C’est toujours galère pour merger 2 branches GIT quand il y a des conflits…
Contexte
J’utilise des git worktrees pour gérer les branches de mes features sur mon projet.
J’ai un répertoire « main » pour la branche main et un répertoire « feature/ma-feature » pour la branche feature/ma-feature.
La branche feature/ma-feature a été créé à partir d’un commit A de la branche main.
Une fois la feature développée, la branche main a eu les commit B, C et D et feature/ma-feature a eu les commit X, Y et Z.
Je souhaite faire une merge request de la feature sur main, mais il faut d’abord que j’applique les modifications qui ont été faite sur main.
Il se trouve que le commit Y a modifié le même fichier qu’un commit de la branche main. Il y aura donc un conflit lors du merge.
Résolution
Le rebase est un processus itératif. Git prend vos commits un par un et tente de les « rejouer » sur la nouvelle base. Si un commit pose problème (conflit), Git s’arrête, vous laisse réparer, puis reprend la suite.
Voici le déroulé précis avec un conflit sur le commit Y.
État Initial
- Main : A -> B -> C -> D
- Feature : A -> X -> Y -> Z
Étape 1 : Mise à jour de main
On récupère les commits B, C, D dans le dossier main.
cd ../main
git pull origin mainÉtape 2 : Lancement du Rebase
On retourne dans la feature et on lance le rebase.
cd ../feature/ma-feature
git rebase mainCe qui se passe immédiatement :
- Git déplace temporairement la branche
featuresur le commit D. - Il prend votre premier commit X et regarde s’il peut l’appliquer sur D.
- Succès : X ne touche pas aux mêmes lignes que B, C ou D. Git crée X’ automatiquement.
Étape 3 : Le Conflit sur Y
Git tente maintenant d’appliquer Y par-dessus X’. Mais là, Y modifie une ligne que le commit C (déjà présent dans main) a aussi modifiée.
Git s’arrête et affiche un message :
CONFLICT (content): Merge conflict in fichier.txt
error: could not apply Y…
À ce stade, le commit Y n’existe pas encore dans la nouvelle lignée. Votre dépôt est dans un état intermédiaire (« REBASING 2/3 »).
Étape 4 : Résolution manuelle
C’est à vous d’intervenir.
- Ouvrez le fichier en conflit. Vous verrez les balises
<<<<<<< HEAD(le code de main + X’) et>>>>>>> Y(votre code). - Modifiez le fichier pour obtenir le résultat final souhaité.
- Dites à Git que c’est réglé :
git add fichier.txt- Relancez la machine :
git rebase --continueÉtape 5 : Application de Y’ et Z’
Une fois que vous avez fait --continue :
- Git crée le commit Y’ avec vos corrections.
- Il passe au commit suivant : Z.
- Si Z ne présente pas de conflit avec Y’, il l’applique automatiquement pour créer Z’.
Le rebase est terminé.
Étape 6 : Publication
Votre historique est maintenant propre : A-B-C-D-X’-Y’-Z’. Il ne vous reste plus qu’à envoyer cela sur le serveur pour mettre à jour votre Merge Request.
git push --force-with-leaseRésumé des commandes en cas de conflit :
git rebase mainGit s’arrête sur Y- Édition manuelle des fichiers
git add .git rebase --continueGit finit le travail avec Zgit push --force-with-lease
Note importante : Si à n’importe quel moment vous paniquez ou si le rebase devient trop complexe, vous pouvez tout annuler et revenir à l’état exact d’avant le rebase avec :
git rebase --abort
Vérification
C’est une étape cruciale. Après un rebase (et surtout après avoir résolu des conflits), il est indispensable de vérifier deux choses :
- L’historique : Est-ce que mes commits sont bien placés après ceux de
main? - Le code : Est-ce que le résultat final correspond à ce que je voulais ? Est-ce que j’ai cassé quelque chose en résolvant les conflits ?
Voici les trois méthodes pour vérifier que tout est parfait.
1. Vérifier l’ordre des commits (La « ligne droite »)
Avant de pousser, vous voulez vous assurer que votre historique est propre.
Commande :
git log --oneline --graph --all -n 10(Le -n 10 limite aux 10 derniers commits pour plus de clarté).
Ce que vous devez voir :
Une ligne droite où vos commits (X’, Y’, Z’) sont juste au-dessus du dernier commit de main (D).
2. Comparer le contenu avec main
Pour voir exactement ce que votre Merge Request va apporter comme changements concrets au projet, vous comparez votre répertoire de feature avec le répertoire main.
Commande :
git diff main- Ce que ça montre : Uniquement les différences entre l’état actuel de votre feature et le sommet de
main. - Ce que vous cherchez : Vous ne devriez voir que vos modifications (celles de X, Y et Z). Si vous voyez du code qui appartient à B, C ou D, c’est que le rebase s’est mal passé.
3. La vérification « Pro » : Comparer avec l’état avant Rebase
C’est la vérification la plus sécurisante. On veut être sûr que le code final de Z’ est identique au code de Z (votre travail original), mais simplement adapté à la nouvelle base.
Puisque vous avez fait un rebase, Git a gardé une trace de votre branche avant l’opération dans ce qu’on appelle le Reflog.
Commande :
git diff feature@{1} feature- Explication :
feature@{1}désigne l’état de votre branche juste avant la dernière grosse opération (le rebase). - Ce que vous cherchez :
- S’il n’y avait aucun conflit, cette commande ne devrait presque rien afficher (ou seulement les changements légitimes liés à la fusion).
- Si vous avez résolu des conflits sur Y, cette commande vous montrera précisément les arbitrages que vous avez faits. C’est le moment idéal pour vérifier que vous n’avez pas supprimé une ligne importante par erreur !
4. Le test ultime : Lancer les tests
Avant de faire le git push --force-with-lease, restez dans votre dossier de feature et lancez votre suite de tests (npm test, pytest, go test, etc.).
Pourquoi c’est important ?
Même si le code semble correct visuellement, le commit C de main a pu modifier une fonction que votre commit X’ utilise. Le code « compile », mais la logique est brisée.
Résumé de la « Checklist » avant de pousser :
git log: L’historique est-il linéaire ?git diff main: Les changements affichés sont-ils bien les miens ?Tests: Est-ce que tout fonctionne encore techniquement ?git push --force-with-lease: Je publie.
