Git: Comment éditer / reformuler le message d'un commit de fusion?
Comment puis-je modifier ou reformuler le message d'un engagement de fusion?
git commit --amend fonctionne si c'est le dernier commit effectué (HEAD), mais que se passe-t-il si il vient avant HEAD?
git rebase -i HEAD~5 ne répertorie pas les commits de fusion.
Si vous ajoutez le --preserve-merges option (ou son synonyme, -p) au git rebase -i _ command alors git essaiera de préserver les fusions lors du rebasement, plutôt que de linéariser l’historique, et vous devriez pouvoir modifier les commits de fusion:
git rebase -i -p HEAD~5
Notez que à partir de git1.7.9.6 (et de git1.7.10 +), git merge lui-même déclenchera toujours l'éditeur , pour vous permettre d'ajouter des détails à une fusion.
"
git merge $tag"pour fusionner une balise annotée ouvre toujours l’éditeur pendant une session de mise à jour interactive. La série v1.7.10 a introduit une variable d’environnement GIT_MERGE_AUTOEDIT pour aider les scripts plus anciens à résoudre ce problème, mais la piste de maintenance devrait également le prendre en charge.
Il introduit également une variable d’environnement GIT_MERGE_AUTOEDIT pour aider les anciens scripts décliner ce comportement.
Voir " Anticiper Git 1.7.1 ":
Récemment, dans un discussion sur la liste de diffusion Git , Linus a admis (et j’ai accepté) que c’était une des erreurs de conception que nous avions commises au début de l’histoire de Git.
Et dans les versions 1.7.10 et suivantes, la commande git merge exécutée dans une session interactive (c’est-à-dire 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 une chance d'expliquer la fusion, tout comme la commande git commit que l'utilisateur exécute après la résolution d'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 problème principal est que git rend trop facile la transmission de mauvais messages de fusion.
Je pense qu’une partie de cela est une idiotie encore plus simple: nous n’avons même jamais lancé l’éditeur par défaut pour une "fusion de git", mais pour un "git commit".
C’était une erreur de conception, et cela signifie que si vous souhaitez réellement ajouter une note à une fusion, vous devez effectuer un travail supplémentaire. Donc, les gens ne le font pas .
Notez qu'avant Git 2.17 (T2 2018), "git rebase -p "messages de journal tronqués d'une validation de fusion, qui est maintenant corrigée.
Voir commit ed5144d (08 févr. 2018) par Gregory Herrero (``) .
Suggéré par: Vegard Nossum (vegard) , et Quentin Casasnovas (casasnovas) .
(Fusion par Junio C Hamano - gitster - dans commit 8b49408 , 27 février 2018)
rebase -p: corrige le message de validation incorrect lors de l'appel degit merge.Depuis commit dd6fb ("
rebase -p: correction de la citation lors de l'appel degit merge", Janvier 2018, Git 2.16.0-rc2), le message de validation de la validation de fusion en cours de rebasage est transmis à la commande de fusion à l'aide d'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 le
git mergecommande.Avant ce correctif, le 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 (T2 2019), A " merge -c "instruction pendant" git rebase --rebase-merges "devrait permettre à l’utilisateur de modifier le message du journal, même s’il n’est pas nécessaire de créer une nouvelle fusion et de remplacer celle qui existe (c’est-à-dire une avance rapide), mais ne l’a pas fait.
Qui a été corrigé.
Voir commit 6df8df (02 mai 2019) par Phillip Wood (phillipwood) .
(Fusionné par Junio C Hamano - gitster - dans commit c510261 , 13 juin 2019)
Une autre bonne réponse 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 (plus correcte) de rebase finale:
git rebase <sha of merge> previous_branch --onto HEAD
En passant, utiliser les commandes primitives pourrait avoir la "fonctionnalité" de Nice de ne pas consommer trop de temps de calcul et de vous faire attendre un temps inconnu jusqu'à ce que Git ait fini de penser à la liste des commits devant être rebasés dans le cas de git rebase -p -i HEAD^^^^ (une telle commande qui aboutirait à une liste de seulement 4 derniers commits avec la fusion, le dernier dans mon cas prenant environ 50 secondes!).
git merge --edit
Vous permet de commenter, même en cas de fusion non interactive.
git merge --edit --no-ff peut être utile si vous suivez git flow avec un rebasement sur une branche de développement et une fusion sans avance rapide.