Aller au contenu
Développement medium
🔐 Alerte sécurité — Incident supply chain Trivy : lire mon analyse de l'attaque

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 tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn