Enlever un commit de l'historique

Bonjour,

Quand je travaille en collaboration sur un texte et que j'utilise git, je me retrouve à faire plusieurs commits unitaires pour apporter des modifications. Seulement, certaines de ces dernières ne sont pas appréciées, donc ne seront pas ajoutées à la branche principale. Je me demandais alors s'il était possible de supprimer un commit d'une branche, c'est-à-dire d'enlever les modifications qu'il introduit.

Par exemple :

• Fichier d'origine

1

# Pouet

• Fichier après commit A

1
2
3

# Pouet

A

• Fichier après commit B

1
2
3
4
5

# Pouet

A

B

• Fichier après commit C

1
2
3
4
5
6
7

# Pouet

A

B

C

Est-il possible d'obtenir facilement le fichier suivant, c'est-à-dire sans tout refaire à la main et, idéalement, en restant sur la même branche ?

1
2
3
4
5

# Pouet

B

C

Merci.

De mon point de vue (qui est sans doute discutable), si tu as besoin de "supprimer" un commit, c'est qu'il y a un problème au niveau de ton branchage.

Personnellement, dès que j'introduis des modifications que je ne suis pas absolument sûr et certain de garder, je branche. Et histoire que ça soit pas le bazar au niveau des merges, j'utilise git merge --no-ff : no fast forward. En gros, ça remplace tous les commits de la branche mergée en un seul. Tellement pratique que ça devrait être le comportement par défaut.

De mon point de vue (qui est sans doute discutable), si tu as besoin de "supprimer" un commit, c'est qu'il y a un problème au niveau de ton branchage.

Pas forcément. Déjà, si tu fais une branche par "hésitation", c'est plutôt toi qui a mal compris à quoi sert une branche dans une méthode de travail traditionnel avec git.

Avec git, une branche = une fonctionnalité/correctif/travail. Si tu fais du code un peu exploratoire ou un peu difficile, il n'est pas rare d'empiler les commits qui ne serviront à rien, mais à ce moment là tu ne sais pas si tu les garderas. Parfois même tu peux être convaincu que c'est bon.

Une fois que tout est bien fini, tu nettoies l'historique en virant et compactant le nécessaire.

Justement, dans une feature, par exemple, je vais pas hésiter à brancher excessivement pour faire de l'exploration ou du code difficile, en sachant que chaque test a sa branche, quitte même à brancher sur mes branches de test. Si ça aboutit, je merge la branche dans la feature, sinon, on en reste là.

Avec un retard, mais un peu de pub pour les ressources internes

Edit : bon fail, il ne parle pas de la suppression de commit, mais juste fusion/changement d'ordre, mais ca reste mentionné dans les messages d'exemple de git.

Ah oui effectivement, je n'avais pas lu le texte en-dessous, seulement la partie "Commands".

Pas forcément. Déjà, si tu fais une branche par "hésitation", c'est plutôt toi qui a mal compris à quoi sert une branche dans une méthode de travail traditionnel avec git. Avec git, une branche = une fonctionnalité/correctif/travail. Si tu fais du code un peu exploratoire ou un peu difficile, il n'est pas rare d'empiler les commits qui ne serviront à rien, mais à ce moment là tu ne sais pas si tu les garderas. Parfois même tu peux être convaincu que c'est bon.

Je ne serais pas si catégorique là-dessus (dans un sens ou dans l'autre d'ailleurs). "Une branche=une fonctionnalité", c'est juste le workflow classique qu'on trouve de partout, ça veut absolument pas dire que git a été construit sur cette philosophie. La philosophie de git, c'est plutôt "tu t'organises comme tu veux, git pourra gérer ton workflow, aussi exotique soit-il". Donc j'ai envie de dire que faire plein de sous-branches dans tous les sens, surtout si c'est en local, c'est tout sauf une incompréhension de la façon dont devrait être utilisé git (et ce qui est de génial c'est que ce ne serait même pas incompatible avec un quelconque branchage sur le dépôt distant commun).