Git merge ou rebase : choisir selon le partage de la branche

Visualiser l’historique avant de choisir

Pendant que vous ajoutez deux commits à feature, main avance également. Merge réunit les deux lignes sans remplacer les commits existants. En cas de divergence, il crée normalement un commit de fusion ; sans divergence à réunir, Git peut simplement avancer le pointeur par fast-forward.

Rebase réapplique vos modifications sur une nouvelle base. Les identifiants changent parce que les ancêtres des commits changent. La lecture peut devenir plus linéaire, mais les collègues ayant récupéré les anciens commits disposent désormais d’un autre historique. Le partage de la branche et les règles du dépôt déterminent le choix.

Préparer la branche et actualiser les références

Commencez par git status et terminez ou mettez à l’abri les modifications non commitées. Récupérez ensuite l’état distant. git fetch origin met à jour origin/main, pas automatiquement la branche locale main. Cette différence évite d’intégrer par erreur une référence ancienne.

L’exemple suppose un distant origin et une branche feature. Une branche de sauvegarde conserve une référence aux commits actuels avant l’intégration. Choisissez un autre nom si celui-ci existe déjà. Utilisez ensuite le parcours merge ou rebase vers origin/main adapté à votre situation, sans exécuter les deux sans raison.

git status
git fetch origin
git switch feature
git branch backup-feature

Préserver l’historique avec merge

Merge convient si les commits existants doivent rester stables. Vérifiez la branche et la résolution des conflits avant de terminer.

git switch feature
git merge origin/main

Rebaser un travail local

Rebase peut rendre une branche locale linéaire. Après les conflits, relisez le diff et relancez les vérifications utiles. Une opération en cours peut être annulée.

git switch feature
git rebase origin/main

Résoudre le sens du conflit

Deux modifications en conflit peuvent exprimer des règles métier différentes. Lisez les versions et leur contexte. Retirer les marqueurs ne suffit pas à déterminer le comportement correct. Ajoutez chaque fichier résolu avec git add puis examinez le diff préparé.

Pour une fusion inachevée, utilisez git merge --continue ou git merge --abort. Pour rebase, utilisez git rebase --continue ou git rebase --abort. Rebase peut s’arrêter de nouveau sur un commit suivant puisqu’il réapplique les changements un à un. --skip ne doit pas servir à faire disparaître une erreur : il peut supprimer les changements du commit.

Relire le résultat et préserver une possibilité de récupération

Comparez le résultat aux modifications attendues et exécutez les vérifications du dépôt. Après un rebase d’une branche déjà publiée, coordonnez sa mise à jour distante. --force-with-lease peut protéger contre une valeur distante inattendue, mais ne remplace ni la coordination ni l’autorisation de réécrire l’historique.

Si l’erreur apparaît après la fin, examinez la branche de sauvegarde et git reflog. Reflog conserve les déplacements locaux des références et peut retrouver l’état antérieur. Créez une branche de récupération depuis le commit identifié avant d’envisager un reset. Évitez reset --hard comme premier réflexe s’il reste du travail non commité.

git reflog --date=iso