Git : supprimer des branches, fusionner et annuler un mauvais push

August 2, 2026 · – visiteurs

Ces trois choses reviennent tout le temps, et pourtant les commandes ne restent jamais vraiment en tête d'une fois sur l'autre. Alors les voici, notées une bonne fois pour toutes.

Supprimer une branche

git branch -d feature-x

C'est la version sûre — Git vérifie d'abord, et refuse si feature-x contient des commits qui ne sont jamais arrivés dans votre branche actuelle. Si vous êtes certain, vous pouvez forcer : (1)

git branch -D feature-x

Cela ne la supprime que localement, cela dit. Si la branche existe aussi sur le remote (GitHub, par exemple), il faut la supprimer là-bas séparément :

git push origin --delete feature-x

Une chose qui vaut la peine d'être sue : supprimer une branche ne supprime pas vraiment ses commits. Ils deviennent simplement non référencés et restent dans le dépôt jusqu'à ce que le ramasse-miettes de Git finisse par les balayer, ce qui peut prendre du temps. Donc git branch -D est plus clément qu'il n'y paraît — si vous supprimez la mauvaise branche, il y a généralement encore un moyen de revenir en arrière (on y revient dans la section sur le reflog plus bas). Je ne compterais pas là-dessus comme plan, mais c'est bon à savoir que ça existe.

Fusionner des branches

Le schéma habituel est : basculez sur la branche dans laquelle vous voulez fusionner, puis fusionnez l'autre dedans.

git checkout main
git merge feature-x

Ce qui se passe ensuite dépend du fait que main ait bougé ou non depuis que vous avez créé la branche. Si elle n'a pas bougé, Git avance simplement le pointeur de main pour qu'il corresponde à feature-x — un fast-forward, sans commit de fusion. Si main a avancé entre-temps, Git crée un véritable commit de fusion qui relie les deux historiques (2).

Parfois vous voulez ce commit de fusion même quand un fast-forward aurait été possible — il laisse une trace visible dans l'historique qu'une branche de fonctionnalité a existé et a été fusionnée, plutôt que de voir le changement se fondre discrètement. Pour ça :

git merge --no-ff feature-x

Si les mêmes lignes ont été touchées des deux côtés, Git s'arrête et vous laisse le conflit à démêler :

git status

Ça listera les fichiers en conflit. Ouvrez chacun d'eux, vous verrez des marqueurs <<<<<<<, ======= et >>>>>>> autour des changements qui s'opposent — choisissez ce qui doit réellement rester, supprimez les marqueurs, puis :

git add resolved-file.txt
git commit

Et si ça tourne au bazar plus qu'autre chose, vous pouvez tout simplement tout abandonner :

git merge --abort

Ça remet tout exactement comme c'était avant que vous ne commenciez la fusion.

Annuler un mauvais push

C'est celui qui fait paniquer les gens, et honnêtement la panique n'est généralement pas justifiée — mais c'est ici que le choix de la solution compte vraiment.

S'il y a la moindre chance que quelqu'un d'autre ait déjà récupéré la branche, ne touchez pas à l'historique. Ajoutez plutôt un nouveau commit qui annule l'ancien :

git revert <bad-commit-sha>
git push

C'est l'option ennuyeuse et toujours sûre. Elle ne réécrit rien — elle ajoute simplement un commit par-dessus qui annule l'erreur, si bien que l'historique de tout le monde reste synchronisé sans que personne n'ait à faire quoi que ce soit de spécial de son côté (3).

Si la branche est vraiment la vôtre et que personne ne l'a encore récupérée, vous pouvez revenir en arrière et réécrire : (4)

git reset --hard <last-good-commit-sha>
git push --force-with-lease

Utilisez --force-with-lease, pas --force tout court, ne serait-ce que par habitude. La différence compte plus qu'il n'y paraît : --force-with-lease vérifie que personne n'a poussé sur la branche depuis votre dernier fetch, et refuse si c'est le cas. --force tout court ne vérifie rien — il écrasera joyeusement le travail de quelqu'un d'autre sans même un avertissement (5).

Et si vous êtes planté devant votre terminal à essayer de vous souvenir quel était le dernier bon commit — git log ne vous aidera pas ici, puisqu'il ne montre que les commits accessibles depuis où vous êtes actuellement, ce qui n'inclut pas ce dont vous vous êtes déjà débarrassé avec le reset. Ce qu'il vous faut, c'est :

git reflog

Ça montre tous les endroits où votre branche a récemment pointé, y compris ceux qui sont sortis de l'historique normal. Remontez jusqu'avant que les choses ne tournent mal, puis : (6)

git reset --hard HEAD@{2}

(remplacez par la position ou le SHA qui correspond réellement à votre cas). Le reflog est local à votre machine et conserve généralement les entrées pendant environ 90 jours, donc c'est moins un « bouton d'annulation d'urgence pour les mauvais push » qu'un filet de sécurité général pour « je crois que je viens de casser un truc » — ça vaut la peine de se rappeler que ça existe, même en dehors de cette situation précise.

Pour conclure

Ces trois choses reposent sur le même fait sous-jacent : Git ne jette presque jamais rien immédiatement. Branches supprimées, commits réinitialisés, anciennes positions sur une branche — tout ça traîne plus longtemps qu'il n'y paraît. C'est vraiment ce qui rend -D, reset --hard et le force-push suffisamment sûrs pour un usage quotidien, tant que vous savez où chercher si l'un d'eux s'avère être une erreur.

Pour aller plus loin

git-branch — création, listage et suppression de branches.
git-merge — stratégies de fusion et résolution de conflits.
git-revert — annuler des commits en en créant de nouveaux.
git-reset — déplacer le pointeur d'une branche, avec la différence entre --soft, --mixed et --hard.
git-push : --force-with-lease — pourquoi c'est plus sûr que --force.
git-reflog — récupérer des commits qui n'apparaissent plus dans l'historique normal.