# make a backup of the current state of your branch
git branch backup your_branch

# reset to the commit prior to A
git reset --hard A^

# then re-apply E
git cherry-pick E
would be a way to do this. Rebase is another (see msanford's very detailed answer on the subject)

Vous pouvez utiliser git reset --hard A ^ pour accéder au dernier "bon" commit, puis git cherry-pick E pour appliquer le commit que vous voulez garder.

Ensuite, vous devez forcer le pousser vers la branche pour réinitialiser les choses. Assurez-vous de faire savoir à tous les autres membres de l'équipe ce qui se passe.

Option avec rebase + drop

Comme Romain l'a suggéré "rebase is another", voici une façon de le faire, en supposant que vous vouliez le résultat final de @ -ABCDE pour être @ -E , comme Lasse l'a demandé.

Je propose ceci comme un autre outil dans votre toolbelt : c'est pas la solution la plus simple à ce problème. Il vous permet cependant de supprimer les commits qui ne sont pas dans l'ordre (supprimer A, C, E et conserver B, D, par exemple):

git push -f

ce qui ouvrira votre éditeur (probablement vi ) avec un tampon qui ressemble à ceci:

pick 4231648cb4 Some previous commit
d 4bccf2ce81 A some message
d 7b4cd5ff17 B some message
d faa44efb7c C some message
d 0ce0525a79 D some message
pick f104648cc3 E some message

Oui, l'ordre des commits de haut en bas est dans l'ordre temporel inverse (l'inverse de git log ) avec le plus récent en bas. C'est pourquoi "les lignes sont exécutées de haut en bas" - du plus ancien au plus récent.

En suivant les instructions, remplacez le mot pick par d code > (ou déposer ) sur les lignes que vous souhaitez supprimer.

pick 4231648cb4 Some previous commit
pick 4bccf2ce81 A some message
pick 7b4cd5ff17 B some message
pick faa44efb7c C some message
pick 0ce0525a79 D some message
pick f104648cc3 E some message

# Rebase 76eb9131b5..ed71142fcb onto 4231648cb4 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Si vous avez commis une erreur irrémédiable, comme la suppression d'une ligne, abandonnez en quittant sans enregistrer (: q! ) et réessayez.

Si tout semble bon, enregistrez et quittez le tampon (: wq ) et continuez à rebaser jusqu'à ce que votre branche soit corrigée.

Si quelque chose de bizarre se produit après cela (comme vous avez changé un hachage de validation en un qui n'existe pas, ou le rebase s'arrête pour faire quelque chose et vous ne savez pas pourquoi) vous pouvez abandonner complètement le rebase avec git rebase --abort qui vous ramènera à votre état initial.

Si votre branche semble correcte, forcez le push. p >

git rebase -i HEAD~6

Une note importante sur la force pushing

Probablement peu connue, mais la stratégie push par défaut avant git 2 est matching , c'est-à-dire g lorsque vous git push , cela va pousser toutes vos branches locales avec les noms de branche distante correspondants, pas seulement votre branche actuelle.

Donc, quand vous git push -f cela forcera le push toutes de vos branches (ceci est arrivé à un collègue hier). Vérifiez avec git config --global push.default . Cela signifie que si vous jouiez avec une autre branche, cela pourrait aussi forcer la pousser.

Je suggérerais changer la stratégie push par défaut en simple si ce n'est pas déjà le cas. Il s'agit de la valeur par défaut de git 2.

Protection des branches

Si vous utilisez une solution git hébergée de manière centralisée comme Stash / BitBucket, Gitlab ou Github, elles offrent toutes une solution so- appelées règles de "protection des branches" pour empêcher, entre autres, les développeurs de pousser de force vers les branches.

Ajouter une règle pour empêcher le push forcé vers le master et probablement la version branches.