Branche Git divergente : merge ou rebase ?

Exemple et conditions

L’exemple est main suivant origin/main, avec deux commits locaux et un distant. Vérifiez vos vrais noms et upstream. Fetch actualise la référence de suivi distante sans intégrer seul son historique à la branche actuelle. Un autre nom de remote ou une branche sans upstream exige des commandes adaptées.

Examiner avant de modifier

Lisez status et branch -vv avant fetch origin. Le comptage gauche/droite de HEAD...origin/main montre les commits exclusifs à chaque côté. Examinez graphe et patches : deux contre un ne dit pas s’ils modifient la même fonction. Une référence périmée ou un comptage isolé ne suffit pas au diagnostic.

git status --short
git branch -vv
git fetch origin
git rev-list --left-right --count HEAD...origin/main
git log --oneline --graph --decorate HEAD origin/main

Garder une référence ou un checkout séparé

Créez rescue/before-sync à la pointe locale et sauvegardez le travail non commité séparément. Une branche garde l’historique commité ; un stash vérifié couvre différemment les fichiers suivis, nouveaux et ignorés. Vérifiez la copie. Intégrer sur du travail local sans rapport complique conflits et récupération.

git branch rescue/before-sync HEAD

Premier parcours

Choisissez merge pour préserver l’historique, surtout si vos commits ont été partagés. Merge origin/main combine l’upstream récupéré avec la branche actuelle et conserve normalement les deux parents en cas de divergence. Examinez le diff et les tests pertinents avant publication. Une intégration terminée ne garantit pas la justesse du code combiné.

git merge origin/main

Choisir l’autre résultat consciemment

Choisissez rebase pour des commits locaux dont l’équipe autorise la réécriture. Rebase origin/main rejoue le travail sur la pointe récupérée, généralement avec de nouveaux identifiants. Des collègues peuvent dépendre des anciens. Un graphe linéaire n’autorise pas à réécrire une branche partagée ou à contourner ses protections.

git rebase origin/main

Limites et exceptions

Pour un conflit de merge, lisez status, résolvez et indexez les fichiers, puis terminez ; merge --abort abandonne l’intégration lorsque ses conditions le permettent. En rebase, résolvez l’étape actuelle et utilisez rebase --continue ; plusieurs arrêts sont possibles. Rebase --abort quitte le rebase actif, sans mélanger les parcours.

git status
git merge --abort

git rebase --abort

Conflits et nettoyage

Reset --hard origin/main n’est pas une réponse générale à la divergence : il retire de cette branche son historique local séparé et peut écraser les fichiers suivis. C’est la décision d’abandonner le travail, tandis qu’ici nous combinons les historiques voulus. Préservez les copies nécessaires avant un autre processus de suppression.

Vérifier le résultat

Vérifiez graphe, état et différence avec origin/main, puis les contrôles du projet. Un push ordinaire peut être refusé si le remote a avancé après fetch. Récupérez et examinez ce nouvel état sans passer automatiquement au force push. Gardez le secours jusqu’à la revue des effets de l’intégration.

git status --short
git log -8 --oneline --graph --decorate
git diff origin/main HEAD

Questions fréquentes

Pourquoi pull demande une stratégie ? Il comprend fetch et un choix d’intégration potentiellement ambigu. Merge évite-t-il les conflits ? Non, les deux méthodes peuvent en rencontrer. Rebase est-il toujours meilleur ? Non : partage des commits et politique d’historique de l’équipe comptent davantage.

Examiner l’opération dans FluxGit

Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.

Références officielles Git

• git-fetch
• git-merge
• git-rebase
• git-pull