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 |
Guides de cette section
Section intitulée « Guides de cette section » Résoudre les conflits de merge Marqueurs de conflit, --ours/--theirs, rerere, --abort : résoudre tous les types de conflits.
Débloquer un push rejeté Comprendre le rejet, pull --rebase, --force-with-lease : débloquer votre push en sécurité.
À 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
Prochaines étapes
Section intitulée « Prochaines étapes » Investiguer et nettoyer Données perdues, fichiers sensibles dans l'historique, débogage de régression.
Opérations Git Vue d'ensemble de tous les guides de résolution de problèmes Git.