Comment modifier un message de commit incorrect dans git (j'ai poussé) ?

Question

Je veux modifier un message de commit plus profondément dans l'historique. Et j'ai poussé beaucoup de nouveaux commits. Comment puis-je modifier le message de commit ? Est-ce possible ?

Merci !

Answer 1

Le message de Linus Torvalds peut répondre à votre question :

Modifier/éditer les anciens messages de commit

Réponse courte : vous ne pouvez pas (si on vous y pousse).

---

extrait (Linus fait référence à BitKeeper comme BK) :

Note complémentaire, juste par intérêt historique : à BK, vous pouviez

Et si vous êtes habitué (comme je l'étais), c'était vraiment très pratique. I appliquais un patch-bombe d'Andrew, remarquais que quelque chose n'allait pas, et juste l'éditer avant de le sortir.

J'aurais pu faire la même chose avec git. Il aurait été assez facile de de faire en sorte que le message de commit ne fasse pas partie du nom, tout en garantissant que l'historique n'a pas été touché, et permettre le "fixer les commentaires plus tard" .

Mais je ne l'ai pas fait.

Il s'agit en partie de pure "cohérence interne". Git est simplement un nettoyant système grâce à la protection SHA1 et au traitement identique de tous les objets, quel que soit leur type. traités de la même manière, quel que soit le type d'objet. Oui, il y a quatre différents types d'objets, et ils sont tous très différents, et ils ne peuvent pas être utilisés de la même manière, mais en même temps, même si leur encodage pourrait être différent sur le disque, conceptuellement ils fonctionnent tous exactement la même chose.

Mais la cohérence interne n'est pas vraiment une excuse pour être inflexible, et clairement ce serait très flexible si nous pouvions juste réparer les erreurs après qu'elles se produisent. Ce n'est donc pas un argument très solide.

Le site réel raison pour laquelle git ne vous permet pas de changer le message de livraison est finalement très simple : de cette façon, vous pouvez faire confiance aux messages. Si vous autorisiez Si vous autorisiez les gens à les modifier après coup, les messages seraient intrinsèquement peu dignes de confiance.

---

Pour être complet, vous pourrait réécrire l'historique des livraisons locales afin de refléter ce que vous voulez, en tant que suggéré par sykora (avec un peu de rebasement et de réinitialisation --dur, haletant !)

Cependant, une fois que vous aurez publié votre histoire révisée à nouveau (avec un git push origin +master:master le + signe forçant le push à se produire, même s'il ne résulte pas en un commit "fast-forward")... vous pourrait avoir des problèmes .

Extrait de cette autre question de l'OS :

Une fois, j'ai poussé avec --force vers le dépôt git.git et je me suis fait gronder par Linus. Cela va créer beaucoup de problèmes pour d'autres personnes. Une réponse simple est "ne le faites pas".

Answer 2

Actuellement, un git remplacer pourrait faire l'affaire.

En détail : Créer une branche de travail temporaire

git checkout -b temp

Remise à zéro de l'engagement à remplacer

git reset --hard <sha1>

Modifier l'engagement avec le bon message

git commit --amend -m "<right message>"

Remplacer l'ancien commit par le nouveau

git replace <old commit sha1> <new commit sha1>

retourner à la branche où vous étiez

git checkout <branch>

supprimer la branche temporaire

git branch -D temp

pousser

guess

fait.

Answer 3

Vous pouvez utiliser git rebase -i (par rapport à la branche d'où vous avez bifurqué) i' pour interactif

remplacer le pick à côté du commentaire de validation que vous souhaitez modifier avec r Sauvegardez et quittez. Vous pourrez alors effectuer la modification.

git push une fois de plus et c'est fini ! =]

Answer 4

Dans notre atelier, j'ai introduit la convention consistant à ajouter des balises annotées au nom reconnaissable aux commits avec des messages incorrects, et à utiliser l'annotation comme remplacement.

Même si cela n'aide pas les personnes qui exécutent des commandes "git log" occasionnelles, cela nous fournit un moyen de corriger les références incorrectes au bug tracker dans les commentaires, et tous mes outils de construction et de publication comprennent cette convention.

Il ne s'agit évidemment pas d'une réponse générique, mais cela pourrait être quelque chose que les gens peuvent adopter au sein de communautés spécifiques. Je suis sûr que si cela est utilisé à plus grande échelle, une sorte de support en porcelaine pour cela peut apparaître, éventuellement...

Answer 5

(De http://git.or.cz/gitwiki/GitTips#head-9f87cd21bcdf081a61c29985604ff4be35a5e6c0 )

Comment modifier les commits plus profondément dans l'histoire

Puisque l'historique dans Git est immuable, corriger quoi que ce soit d'autre que le commit le plus récent (commit qui n'est pas la tête de branche) nécessite que l'historique soit réécrit à partir du commit modifié et au-delà.

Vous pouvez utiliser StGIT pour cela, initialiser la branche si nécessaire, désengager jusqu'au commit que vous voulez modifier, y aller si nécessaire, faire une modification puis rafraîchir le patch (avec l'option -e si vous voulez corriger le message du commit), puis pousser le tout et faire un commit stg.

Ou vous pouvez utiliser rebase pour le faire. Créez une nouvelle branche temporaire, remontez-la jusqu'au commit que vous voulez modifier en utilisant git reset --hard, modifiez ce commit (il sera au sommet de la tête actuelle), puis rebasez la branche au sommet du commit modifié, en utilisant git rebase --onto .

Ou vous pouvez utiliser git rebase --interactive, qui permet diverses modifications comme le réordonnancement des patchs, leur réduction, ...

Je pense que cela devrait répondre à votre question. Cependant, notez que si vous avez poussé vers un dépôt distant et que des personnes s'en sont inspirées, cela va perturber l'historique de leur code, ainsi que le travail qu'ils ont effectué. Faites-le donc avec précaution.