Le message rejected (non-fast-forward) indique que la branche distante contient des commits que votre branche locale n’intègre pas. Git refuse le push pour éviter de les faire disparaître de l’historique distant.
Examiner avant de modifier l’historique
Depuis le dépôt et la branche concernés :
git status -sb
git branch -vv
git remote -v
git fetch origin
Vérifiez le nom de la branche et du dépôt distant. git fetch actualise les références distantes sans modifier votre branche ni vos fichiers. Dans les exemples suivants, remplacez ma-branche par la branche réellement suivie. Si votre remote ne s’appelle pas origin, remplacez aussi ce nom.
git log --oneline --left-right --graph HEAD...origin/ma-branche
Les lignes précédées de < sont propres à votre branche ; celles précédées de > sont propres à la branche distante. Si origin/ma-branche n’existe pas, vérifiez le nom de la branche distante avec git branch -r avant de continuer.
Préserver les modifications non commitées
Avant un rebase ou une fusion, git status doit être clair, ou vos changements doivent être mis à l’abri. Le plus simple est de terminer et commiter le travail prêt. Pour un travail provisoire, git stash push -u -m "Avant synchronisation" inclut aussi les fichiers non suivis, mais pas les fichiers ignorés. Contrôlez la liste avec git stash list ; restaurez ensuite avec git stash pop et résolvez d’éventuels conflits.
Une branche de sauvegarde protège les commits locaux, pas les modifications non commitées :
git branch sauvegarde-avant-sync
Choisissez un autre nom si cette branche existe déjà.
Intégrer les commits distants
Choisissez une méthode selon les règles de votre équipe.
| Méthode | Quand l’utiliser | Commande |
|---|---|---|
| Rebase | Vos commits locaux ne sont pas déjà partagés et vous voulez un historique linéaire | git rebase origin/ma-branche |
| Fusion | Vous voulez conserver explicitement les deux historiques | git merge origin/ma-branche |
Le rebase rejoue vos commits locaux sur la branche distante et change leurs identifiants. N’utilisez pas cette méthode sur des commits déjà repris par d’autres personnes sans coordination. Une fusion crée un commit de fusion si les historiques ont divergé.
En cas de conflit, lisez git status, ouvrez les fichiers signalés et gardez le contenu voulu. Puis :
git add chemin/du/fichier
git rebase --continue
Pour une fusion, remplacez la dernière commande par git merge --continue. Pour revenir à l’état d’avant l’opération en cours, utilisez git rebase --abort ou git merge --abort selon la méthode choisie. Ces commandes abandonnent les résolutions déjà effectuées pendant l’opération : conservez-les d’abord si nécessaire.
Vérifier puis pousser
git status
git log -5 --oneline --decorate
git push origin ma-branche
Lancez les tests du projet et vérifiez que les commits distants et les vôtres sont présents. Si le push est encore refusé, quelqu’un a pu pousser entre votre fetch et votre push : récupérez à nouveau l’état distant et recommencez la comparaison.
Évitez git push --force pour résoudre ce cas. Un push forcé peut remplacer des commits distants. Si le message parle plutôt de branche protégée, de droits insuffisants ou de contrôle CI, traiter ces règles séparément ne se résout pas par un rebase.

