Aller au contenu
Développement medium

Conflits et synchronisation Git : merge, push rejeté

3 min de lecture

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.

SituationCauseSolution
CONFLICT lors d'un merge ou rebaseDeux branches ont modifié la même zoneRésoudre manuellement les marqueurs puis git add + git merge --continue
! [rejected] lors d'un pushLe remote a des commits que votre branche locale n'a pasgit pull --rebase puis push
Push rejeté sur branche partagée après rebaseHistorique local diverge du remote (rebase réécrit les SHA)git push --force-with-lease après coordination avec l'équipe
  • Un conflit n'efface rien : Git marque les zones conflictuelles avec <<<<<<<, =======, >>>>>>>, c'est vous qui tranchez
  • git pull --rebase est préférable à git pull (merge) : l'historique reste linéaire
  • --force-with-lease est plus sûr que --force : il échoue si quelqu'un a pushé entre-temps
  • Ne jamais force-pusher main ou toute branche partagée sans coordination d'équipe
  • git merge --abort et git rebase --abort annulent proprement si vous vous êtes trompé de stratégie

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn