Enlever un commit de l'historique

Le problème exposé dans ce sujet a été résolu.

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.

+0 -0

Pour réécrire l'histoire, tu dois utiliser le rebase. Positionne toi sur ton projet et regarde la liste de tes commits :

1
git log --oneline

Si tu veux supprimer les modifications faites dans le 3eme et 5eme commit, tu indiques à git que tu veux réécrire l'histoire jusqu'au 5eme commit :

1
git rebase -i HEAD~5

Git va ouvrir vi (par défaut) avec la liste des 5 derniers commits de la branche et un mot clé devant chaque commit. Par défaut, le mot clé est "pick". En résumé, cela signifie qu'il ne va pas toucher au commit si tu laisses ce mot clé. Tu peux le modifier pour d'autres mots clés, ils sont énumérés en commentaire plus bas dans la console.

Pour supprimer le 3eme et 5eme commit, il suffit de supprimer les lignes où sont écrites les commits et ça supprimera automatiquement ces commits de l'histoire de ta branche.

Cette manipulation est irreversible. Pense à sauvegarder ta branche quelque part, dans une autre branche en local ou dans un dépôt distant pour la récupérer intact en cas de pépin.

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.

+0 -0

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à.

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).

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte