16 thoughts on “Annuler les derniers commits avec Git”

• 

  ZZelle 29/06/2014 at 09:11

  Pour inverser les derniers commits, il vaut mieux utiliser git rebase -i.
  Pour inverser les 2 derniers commits:
  
#$ git log --oneline -2 # Affiche 2 derniers commits
d3e5d39 Use patch ports to interconnect integration/physical bridges
8df1e96 Increase default metadata_workers, backlog to 4096

  #$ git rebase -i HEAD^^ # on arrive dans votre éditeur favori avec les 2 derniers commits
  pick d3e5d39 Use patch ports to interconnect integration/physical bridges
  pick 8df1e96 Increase default metadata_workers, backlog to 4096

  # On échange les 2 lignes
  pick 8df1e96 Increase default metadata_workers, backlog to 4096
  pick d3e5d39 Use patch ports to interconnect integration/physical bridges

  # On sauve et on quitte l'éditeur

  #$ git log --oneline -2 # Affiche 2 derniers commits
xxxxxxx Use patch ports to interconnect integration/physical bridges
yyyyyyy Increase default metadata_workers, backlog to 4096
#Les sha1 changent


• 

  Sam Post author 29/06/2014 at 09:20

  Félicitation, tu viens juste de réécrire ton historique, t’assurant que ton prochain push ou pulll ne marchera pas si les commits sont publiques, boussillant ta syncro avec les historiques des autres commiters, et rendant difficile la récupération de toute modif des commits qut tu as annulé.

  C’est ce que je disais par:

  La plupart sont dangereuses ou ont un résultat inattendu, présuppose un état de votre repo ou va vous mettre dans une situation que vous ne maîtrisez pas.

  La méthode que tu propose ne marche que si tu n’as jamais pushé ou mergé les dits commits. Si quelqu’un sur le web lis ta méthode et l’utilise sur des commits pushés ou mergés, tu vas le mettre dans une merde pas croyable, et il aura aucune idée de pourquoi.

• 

  Blef 29/06/2014 at 09:26

  @ZZelle je pense que ce que Sam soulève comme problème c’est si on a déjà push la branche par exemple. Donc à part si on veut se faire arracher par ses collègues en forçant un push on est obligé de faire ce genre d’opération

• 

  Blef 29/06/2014 at 09:29

  Ouais voilà hein. Sinon astuce, plutôt que de faire un git reset –hard HEAD j’aime bien faire un git checkout . ça me fait économiser de la frappe !

• 

  Sam Post author 29/06/2014 at 09:47

  @Blef: ouai, mais ça fait que switcher les fichiers changés, il me semble ça del pas ceux qui ne sont pas dans les autres commits.

• 

  irongomme 30/06/2014 at 10:05

  Génial !

  Exactement ce dont j’avais besoin !!

• 

  Sanao 30/06/2014 at 18:29

  Le terme plus exacte est annuler les derniers commits.

  Je trouve que inverser est “confusant” au sens où l’on a l’impression que tu veux réécrire ton historique en changeant l’ordre de tes commits.

• 

  G-rom 30/06/2014 at 21:04

  Idem, tu devrais mettre “annuler” au lieu de “inverser”. D’ailleurs @ZZelle t’as pris au mot, sa méthode inverse bien les 2 derniers commit

• 

  Sam Post author 01/07/2014 at 04:36

  Inverser: Mettre dans le sens contraire.

  C’est ici exactement ce que l’on fait.

  On avait les commit :

  C
  B
  A

  Et on fait un commit de plus, qui fait :

  A
  B
  C
  C
  B
  A

  Le fait que le BCA soit fait en un seul commit ne doit pas vous tromper. On appliquer bien exactement l’inverse de la série de commit précédents.

  Effectivement, on annule bien les dernier commits, dans le sens supprime leurs effets. On les annule en plaçant une série de modifications parfaitement symétriques : l’inverse des commits précédents.

  La raison pour laquelle j’ai choisi inverser et non annuler comme mot, c’est que l’on peut annuler (supprimer les effets de) de plusieurs manières. Des manières qu’il vaut mieux éviter à moins de savoir exactement ce que l’on fait.

  La méthode de ZZelle, annule les commits, mais pas par inversion. Par suppression. C’est ce qui rend la méthode dangereuse : en supprimant une partie de l’historique, on se maintenant s’assurer que tous les autres clones fassent la même modification (et pas d’autres) dans le même temps. Une situation très difficile à gérer.

• 

  kontre 01/07/2014 at 19:58

  Inverser a un autre sens de celui que ce que tu prends, Sam. Ça veut aussi dire prendre un truc, le mettre à la place d’un machin, et mettre le machin là où était le truc. C’est ce que j’avais compris de ton titre. Tu devrais changer ton titre, là c’est trop ambigu. Je préfère annuler: on a fait un truc, et on veut le défaire. Y’a plusieurs manières d’annuler, mais aussi plusieurs manières d’inverser !

  ZZelle ne supprime rien et n’annule, elle chamboulle l’historique. en échangeant 2 commits. C’est dangereux, mais pas mal de giteux trouvent ça élégant, notamment pour les pull requests. Numpy demande à ce qu’un pull request soit compacté en un unique commit avant de merger, par exemple, pour garder l’hisorique global du projet plus clean.

• 

  Sam Post author 02/07/2014 at 03:37

  Ok pour le changement de titre.

  Par contre, je fais pas de tuteux pour les giteux. Je le fais pour ceux qui pigent pas git. Et j’en vois tous les jours qui suivent les tutos à base de reset –hard et de rebase et autres joyeuseté et qui bousillent leur environnement de travail à cause de ça. Ils perdent des jours là dessus. Parfois ils abandonnent Git juste à cause de ça. Franchement ça m’énerve quand on donne ces techniques dangereuses, c’est irresponsable. Au moins mettre un label énorme en rouge, et proposer AVANT l’alternative safe. Les gens se rendent pas compte…

  Par ailleurs, le fait de compacter ses commits pour un pull request est une problématique différente. Ici on parle d’annuler un commit, et je pense que c’est beaucoup plus clair d’avoir une trace de l’annulation dans l’historique. De plus, compacter, c’est nécessaire sur un gros projet pour la lisibilité de l’histo. Mais franchement, pour une équipe qui a 3 dev, ce n’est pas du tout nécessaire. Qu’on recommande ça partout, juste pour “avoir un bel historique” ça me fout les nerfs. Est-ce que vous savez combien de personnes se sont fait niquez en faisant un rebase ? C’est une technique super advance, à recommander uniquement à ceux qui savent ce qu’ils font.

• 

  Sam Post author 02/07/2014 at 03:39

  Merci d’avoir insisté pour changer le titre. C’est le genre de chose qu’on a tendance à ne pas voir (et même à ne pas vouloir voir) quand on a écrit l’article. Si il y avait juste une personne qui m’avait dit ça, je ne l’aurais pas fait. Mais comme vous avez tous, gentiment et patiemment, expliqué qu’il fallait le changer, ça a finit par rentrer.

  Je ne le répète pas assez, mais vous êtes un super lectorat et je suis très content de vous avoir en comment.

• 

  foxmask 04/07/2014 at 07:05

  un lien git merge vs rebase pour ceux qui passeraient par ici

• 

  chaiyachaiya 04/07/2014 at 20:17

  Juste en passant, “…git reset –hard HEAD. Attention, cette dernière commande n’est pas réversible…” n’est pas tout à fait vrai.
  La commande reflog de git permet de revenir à une position donnée du HEAD par lequel il est passé. Mais c’est un peu le coté obscur de git.

  Sinon pour être sûr d’avoir bien compris. Si je faisais un revert pour chaque commit et qu’ensuite je squash l’ensemble des commits de revert en un seul commit, on obtient le même résultat ?

• 

  Sam Post author 05/07/2014 at 02:51

  Cette command va aussi remettre à plat la copie de travail, et toute modif de celle-ci n’est pas dans l’histo git, donc on ne peut pas récupérer ça via git reflog.

  Avec le squash, on obtient le même résultat, si tu fais el squash avant la publication des commits.

• 

  ben 15/04/2015 at 13:02

  Merci pour le tutot ;)