Un push rejeté ou un conflit de merge ne signifient pas que quelque chose est cassé. Ce sont des mécanismes de protection : Git vous dit que deux historiques ont divergé et qu'il a besoin de votre décision pour les réconcilier.
Ces deux situations ont des causes et des solutions distinctes, mais une logique commune : comprendre qui a quoi, puis décider comment fusionner.
Comprendre la différence
Section intitulée « Comprendre la différence »| Situation | Cause | Solution |
|---|---|---|
CONFLICT lors d'un merge ou rebase | Deux branches ont modifié la même zone | Résoudre manuellement les marqueurs puis git add + git merge --continue |
! [rejected] lors d'un push | Le remote a des commits que votre branche locale n'a pas | git pull --rebase puis push |
Push rejeté sur branche partagée après rebase | Historique local diverge du remote (rebase réécrit les SHA) | git push --force-with-lease après coordination avec l'équipe |
Quel guide pour quelle situation ?
Section intitulée « Quel guide pour quelle situation ? »Résoudre les conflits de merge couvre les
marqueurs de conflit, les options --ours et --theirs, rerere et
--abort pour résoudre tous les types de conflits.
Débloquer un push rejeté explique d'abord
pourquoi Git refuse, puis pull --rebase et --force-with-lease pour
débloquer le push en sécurité. Lisez-les dans cet ordre si vous hésitez :
un push rejeté mène souvent à un conflit à résoudre.
À retenir
Section intitulée « À retenir »- Un conflit n'efface rien : Git marque les zones conflictuelles avec
<<<<<<<,=======,>>>>>>>, c'est vous qui tranchez git pull --rebaseest préférable àgit pull(merge) : l'historique reste linéaire--force-with-leaseest plus sûr que--force: il échoue si quelqu'un a pushé entre-temps- Ne jamais force-pusher
mainou toute branche partagée sans coordination d'équipe git merge --abortetgit rebase --abortannulent proprement si vous vous êtes trompé de stratégie