Git: Comment modifier / reformuler le message d'un commit de fusion?

Comment modifier ou reformuler le message d'un commit de fusion?

git commit --amendfonctionne si c'est le dernier commit effectué ( HEAD), mais que se passe-t-il s'il vient avant HEAD?

git rebase -i HEAD~5 ne répertorie pas les validations de fusion.

Si vous ajoutez l' --preserve-mergesoption (ou son synonyme -p) à la git rebase -icommande, git essaiera de conserver les fusions lors du rebasage, plutôt que de linéariser l'historique, et vous devriez également pouvoir modifier les commits de fusion:

git rebase -i -p HEAD~5

Notez que, à partir de git1.7.9.6 (et git1.7.10 +), git mergelui - même déclenchera toujours l'éditeur , pour que vous puissiez ajouter des détails à une fusion.

" git merge $tag" pour fusionner une balise annotée ouvre toujours l'éditeur lors d'une session d'édition interactive. La série v1.7.10 a introduit une variable d'environnement GIT_MERGE_AUTOEDIT pour aider les scripts plus anciens à refuser ce comportement, mais la piste de maintenance devrait également le prendre en charge.

Il introduit également une variable d'environnement GIT_MERGE_AUTOEDITpour aider les scripts plus anciens à refuser ce comportement.

Voir « Anticipation de Git 1.7.10 »:

Récemment, lors d'une discussion sur la liste de diffusion Git , Linus a admis (et j'ai accepté) que c'était l'une des erreurs de conception que nous avons commises au début de l'histoire de Git.
Et dans la 1.7.10 et les versions ultérieures, la commande git merge qui est exécutée dans une session interactive (c'est-à-dire à la fois son entrée standard et sa sortie standard connectée à un terminal) ouvrira un éditeur avant de créer un commit pour enregistrer le résultat de la fusion, pour donner l'utilisateur a une chance d'expliquer la fusion, tout comme la commande git commit que l'utilisateur exécute après avoir résolu une fusion en conflit le fait déjà.

Linus a dit:

Mais je ne me soucie pas vraiment de la façon dont cela fonctionne réellement - mon principal problème est que git rend beaucoup trop facile d'avoir de mauvais messages de fusion.
Je pense qu'une partie de cela est une idiotie encore plus simple: nous negit commit
lançons même jamais l'éditeur par défaut pour un "git merge", mais nous le faisons pour un " ". C'était une erreur de conception, et cela signifie que si vous voulez ajouter une note à une fusion, vous devez faire un travail supplémentaire. Alors les gens ne le font pas .

Notez qu'avant Git 2.17 (Q2 2018), " git rebase -p" les messages de journal déformés d'un commit de fusion sont désormais corrigés.

Voir commit ed5144d (08 février 2018) par Gregory Herrero (``) .
Suggéré par: Vegard Nossum ( vegard) et Quentin Casasnovas ( casasnovas) .
^{(Fusionné par Junio ​​C Hamano - gitster- in commit 8b49408 , 27 fév 2018)}

rebase -p: corrige un message de validation incorrect lors de l'appel git merge.

Depuis commit dd6fb00 (" rebase -p: fix citant lors de l'appel git merge", janvier 2018, Git 2.16.0-rc2), le message de commit du commit de fusion en cours de rebasage est passé à la commande merge en utilisant un sous-shell exécutant ' git rev-parse --sq-quote'.

Des guillemets doubles sont nécessaires autour de ce sous-shell afin que les nouvelles lignes soient conservées pour la git mergecommande.

Avant ce patch, message de fusion suivant:

"Merge mybranch into mynewbranch

Awesome commit."

devient:

"Merge mybranch into mynewbranch Awesome commit."

après un rebase -p.

Avec Git 2.23 (Q2 2019), une merge -cinstruction " " pendant " git rebase --rebase-merges" devrait donner à l'utilisateur une chance d'éditer le message du journal, même s'il n'est pas nécessaire de créer une nouvelle fusion et de remplacer l'existant (c'est-à-dire d'avance rapide à la place ), mais pas.
Ce qui a été corrigé.

Voir commit 6df8df0 (02 mai 2019) par Phillip Wood ( phillipwood) .
^{(Fusionné par Junio ​​C Hamano - gitster- in commit c510261 , 13 juin 2019)}

Une autre bonne réponse en utilisant uniquement des commandes primitives - par knittl https://stackoverflow.com/a/7599522/94687 :

git checkout <sha of merge>
git commit --amend # edit message
git rebase HEAD previous_branch

ou une meilleure commande de rebase finale (plus correcte):

git rebase <sha of merge> previous_branch --onto HEAD

BTW, l'utilisation des commandes primitives pourrait avoir la bonne "fonctionnalité" de ne pas consommer trop de CPU et de vous faire attendre un temps inconnu jusqu'à ce que Git finisse de penser à la liste des commits devant être rebasés dans le cas de git rebase -p -i HEAD^^^^(une telle commande qui entraînerait une liste de seulement 4 derniers commits avec la fusion comme dernier dans mon cas dans mon cas a pris environ 50 secondes!).

git merge --edit
Vous permet de donner le commentaire même en cas de fusion non interactive.

git merge --edit --no-ff peut être utile si vous suivez git flow avec rebasage sur la branche de développement et fusion avec elle sans avance rapide.

Pour les versions actuelles de Git (Mai 2020):

git rebase -i -r <parent>,

puis remplacez dans l'éditeur merge -C ...par merge -c ....

Cela ouvrira le message de validation dans l'éditeur lors du rebasage, où vous pourrez le modifier.

(Merci à VonC pour l' allusion .)

La git rebase -i HEAD~5commande fait apparaître l'éditeur. Il répertorie les commits spécifiés (dans ce cas, cinq d'entre eux). La première colonne contient pickpour chaque commit. Remplacez simplement pickpar reworddans cet éditeur et enregistrez + fermez l'éditeur. Ensuite git affiche l'éditeur pour tous les commits où vous avez changé pickà rewordet vous permettra de modifier le message de livraison .