Débloquer un push Git rejeté

Votre git push affiche rejected et non-fast-forward ? C’est le symptôme le plus courant en travail d’équipe : quelqu’un a poussé des commits pendant que vous travailliez. Ce guide vous montre comment débloquer la situation avec pull --rebase, quand utiliser --force-with-lease, et comment diagnostiquer les divergences entre votre branche locale et le remote.

Prérequis : Remotes fondamentaux et Branches distantes.

Ce que vous allez apprendre

• Comprendre pourquoi un push est rejeté (divergence de branches)
• Résoudre le rejet avec pull --rebase puis re-push propre
• Utiliser --force-with-lease en toute sécurité quand nécessaire
• Diagnostiquer les divergences entre local et remote
• Configurer pull.rebase pour éviter les merges parasites automatiques

Comprendre le message d’erreur

Quand vous tentez un push et que le remote a avancé entre-temps :

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch
hint: is behind its remote counterpart.

En clair : votre branche locale est en retard par rapport au remote. Git refuse de pusher parce que cela écraserait les commits de vos collègues.

Remote:  A — B — C — D (commit de votre collègue)
Local:   A — B — C — E (votre commit)

Le remote a D, vous avez E. Git ne peut pas simplement ajouter E après D car il remplacerait D.

Solution standard : git pull —rebase

Dans 90% des cas, la solution est simple :

git pull --rebase

Cette commande fait deux choses :

1. Récupère les nouveaux commits du remote (git fetch)
2. Rejoue vos commits locaux après les commits du remote

Résultat :

Avant:   A — B — C — D (remote)
                  \— E (local)

Après:   A — B — C — D — E' (linéaire ✓)

Votre commit E est rejoué comme E’ (nouveau SHA, même contenu) après le commit D de votre collègue. L’historique reste linéaire.

Ensuite, poussez normalement :

git push

Si des conflits apparaissent

Pendant le rebase, Git peut rencontrer des conflits :

1. Résolvez les conflits dans chaque fichier

   git status
   # Éditez les fichiers listés sous "Unmerged paths"

2. Ajoutez les fichiers résolus

   git add fichier-resolu.py

3. Continuez le rebase

   git rebase --continue

4. Poussez

   git push

Pour annuler le rebase en cours et revenir à l’état d’avant :

git rebase --abort

Alternative : git pull (merge)

Si vous préférez un merge classique au lieu d’un rebase :

git pull

Cela crée un commit de merge :

A — B — C — D ——— M (merge commit)
              \— E ─┘

Résultat fonctionnel identique, mais l’historique contient un point de fusion supplémentaire. Le push fonctionne ensuite normalement.

Rebase vs merge pour les pulls

pull --rebase produit un historique linéaire (plus propre). pull (merge) préserve l’historique tel quel (plus fidèle).

La plupart des équipes préfèrent le rebase pour les pulls courants. Configurez-le par défaut (voir section suivante).

Configurer pull.rebase par défaut

Configuration recommandée : à faire une fois

Configurer pull.rebase true globalement évite 90 % des push rejetés causés par des divergences. À faire dès l’installation de Git :

git config --global pull.rebase true

Pour ne plus avoir à taper --rebase à chaque pull :

git config --global pull.rebase true

Vérification :

git config --global pull.rebase
# true

Désormais, git pull fera automatiquement un rebase au lieu d’un merge.

Quand utiliser —force-with-lease

--force-with-lease force le push mais vérifie d’abord que personne n’a poussé entre-temps. C’est un « force push sécurisé ».

Cas légitimes

Situation	Pourquoi le push est rejeté	Solution
Vous avez fait --amend sur un commit déjà poussé	Le SHA a changé	--force-with-lease
Vous avez fait un rebase -i sur une branche poussée	Les SHA ont changé	--force-with-lease
Vous avez fait un reset sur une branche poussée	Des commits ont disparu	--force-with-lease

Glissez pour voir

git push --force-with-lease

Différence avec —force

Commande	Comportement
git push --force	Écrase le remote sans vérification — dangereux
git push --force-with-lease	Vérifie que le remote n’a pas changé depuis votre dernier fetch — sûr

Glissez pour voir

Jamais --force sur une branche partagée

git push --force peut écraser le travail de vos collègues sans avertissement. Utilisez toujours --force-with-lease à la place. Et même avec --force-with-lease, ne l’utilisez que sur des branches où vous êtes le seul contributeur (feature branches personnelles).

Pour une branche partagée comme main, utilisez toujours git pull --rebase puis git push.

Diagnostiquer une divergence

Quand la situation est confuse, diagnostiquez avant d’agir :

Voir l’état des branches locale vs remote

git fetch
git log --oneline --left-right HEAD...origin/main

Sortie typique :

< a1b2c3d (HEAD -> main)   votre commit local
< d4e5f6a                  votre commit local
> f7a8b9c (origin/main)    commit du remote
> 1234abc                  commit du remote

• < = commits présents localement mais pas sur le remote
• > = commits sur le remote mais pas localement

Compter les commits d’écart

git rev-list --count HEAD..origin/main
# Nombre de commits que le remote a en plus

git rev-list --count origin/main..HEAD
# Nombre de commits que vous avez en plus

Visualiser le graphe

git log --oneline --graph --all

Cela montre clairement où les branches ont divergé.

Cas spécial : push rejeté après un rebase local

Si vous avez rebasé votre feature branch sur main localement, les SHA de vos commits ont changé. Le push sera rejeté car le remote a les anciens SHA :

# Vous avez fait :
git switch feature/login
git rebase main

# Le push est rejeté :
git push
# ! [rejected] feature/login -> feature/login (non-fast-forward)

Solution — c’est un cas légitime pour --force-with-lease (si vous êtes seul sur cette branche) :

git push --force-with-lease

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
rejected après pull --rebase	Conflit non résolu pendant le rebase	git rebase --continue après résolution, ou git rebase --abort
--force-with-lease aussi rejeté	Quelqu’un a poussé depuis votre dernier fetch	git fetch puis réessayez, ou faites pull --rebase
Push rejeté sur une branche que personne ne touche	Votre tracking branch est mal configurée	git push -u origin feature/login
everything up-to-date mais les commits manquent	Vous n’êtes pas sur la bonne branche	Vérifiez git branch et git log --oneline -5
Push OK mais les commits n’apparaissent pas sur GitHub	Poussé sur la mauvaise branche distante	git push origin feature/login:feature/login

Glissez pour voir

À retenir

• Push rejeté = le remote a avancé — c’est normal en équipe
• git pull --rebase résout 90% des cas en gardant un historique linéaire
• --force-with-lease est le force push sécurisé — uniquement après un amend/rebase sur une branche personnelle
• Jamais --force sur une branche partagée
• pull.rebase = true évite d’avoir à taper --rebase à chaque fois
• Diagnostiquez avec git log --left-right HEAD...origin/main avant d’agir dans le doute

Prochaines étapes

Résoudre les conflits de merge Marqueurs, --ours/--theirs, rerere et résolution de conflits.

Workflows Git Feature branch, Gitflow, trunk-based : choisir le bon workflow d'équipe.

Remotes fondamentaux Maîtrisez fetch, pull, push et la gestion des dépôts distants.

×

📖 Voir la documentation →