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

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 ?

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.

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.

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.

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.

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.