Git: Como editar / reformular a mensagem de uma consolidação de mesclagem?

Como edito ou reformulo a mensagem de uma consolidação de mesclagem?

git commit --amendfunciona se for o último commit efetuado ( HEAD), mas e se vier antes HEAD?

git rebase -i HEAD~5 não lista os commits de mesclagem.

Se você adicionar a --preserve-mergesopção (ou seu sinônimo -p) ao git rebase -icomando, o git tentará preservar as mesclagens ao rebasear, em vez de linearizar o histórico, e você poderá alterar também os commits de mesclagem:

git rebase -i -p HEAD~5

Observe que, iniciando o git1.7.9.6 (e git1.7.10 +), git mergeele próprio sempre acionará o editor , para que você adicione detalhes a uma mesclagem.

" git merge $tag" para mesclar uma tag anotada sempre abre o editor durante uma sessão de edição interativa. A série v1.7.10 introduziu uma variável de ambiente GIT_MERGE_AUTOEDIT para ajudar scripts mais antigos a recusar esse comportamento, mas a faixa de manutenção também deve suportá-lo.

Ele também apresenta uma variável de ambiente GIT_MERGE_AUTOEDITpara ajudar os scripts mais antigos a recusar esse comportamento.

Veja " Antecipando o Git 1.7.10 ":

Recentemente, em uma discussão na lista de discussão do Git , Linus admitiu (e eu concordei) que esse foi um dos erros de design que cometemos no início da história do Git.
E no 1.7.10 e posterior, o comando git merge que é executado em uma sessão interativa (ou seja, sua entrada padrão e sua saída padrão conectada a um terminal) abrirá um editor antes de criar uma confirmação para registrar o resultado da mesclagem, para fornecer o usuário tem a chance de explicar a mesclagem, assim como o comando git commit que o usuário executa depois de resolver uma mesclagem em conflito.

Linus disse:

Mas eu realmente não me importo profundamente como ele realmente funciona - meu problema principal é que o git facilita demais as mensagens de mesclagem incorretas.
Eu acho que parte disso é uma idiotice ainda mais simples: nós nunca acionamos o editor por padrão para uma "mesclagem de git", mas fazemos para uma " git commit".
Isso foi um erro de design, e significa que, se você deseja realmente adicionar uma nota a uma mesclagem, precisará fazer um trabalho extra. Então as pessoas não .

Observe que, antes do Git 2.17 (Q2 2018), git rebase -pas mensagens de log " " mutiladas de uma consolidação de mesclagem, que agora está corrigida.

Veja commit ed5144d (08 de fevereiro de 2018) por Gregory Herrero (``) .
Sugerido por: Vegard Nossum ( vegard) e Quentin Casasnovas ( casasnovas) .
^{(Mesclado por Junio ​​C Hamano - gitster- no commit 8b49408 , 27 de fevereiro de 2018)}

rebase -p: corrigir mensagem de confirmação incorreta ao chamar git merge.

Como o commit dd6fb00 (" rebase -p: correção de citação ao chamar git merge", janeiro de 2018, Git 2.16.0-rc2), a mensagem de commit do commit de mesclagem que está sendo reformulada é passada para o comando mesclar usando um subshell executando ' git rev-parse --sq-quote'.

As aspas duplas são necessárias em torno deste subshell para que sejam mantidas novas linhas para o git mergecomando.

Antes desse patch, a seguinte mensagem de mesclagem:

"Merge mybranch into mynewbranch

Awesome commit."

torna-se:

"Merge mybranch into mynewbranch Awesome commit."

depois de um rebase -p.

Com o Git 2.23 (Q2 2019), uma " merge -c" instrução durante " git rebase --rebase-merges" deve permitir ao usuário editar a mensagem de log, mesmo quando não houver necessidade de criar uma nova mesclagem e substituir a existente (por exemplo, avançar rapidamente ), mas não o fez.
O que foi corrigido.

Veja commit 6df8df0 (02 de maio de 2019) de Phillip Wood ( phillipwood) .
^{(Incorporado por Junio ​​C Hamano - gitster- in commit c510261 , 13 jun 2019)}

Outra boa resposta usando apenas comandos primitivos - por knittl https://stackoverflow.com/a/7599522/94687 :

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

ou um comando de rebase final melhor (mais correto):

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

BTW, o uso dos comandos primitivos pode ter o bom "recurso" de não consumir muita CPU e fazer com que você espere um tempo desconhecido até o Git terminar de pensar na lista de confirmações que precisam ser reformuladas no caso de git rebase -p -i HEAD^^^^(um comando que resultaria em uma lista de apenas quatro últimos commit com a mesclagem, já que o último no meu caso, no meu caso, levou cerca de 50 segundos!).

git merge --edit
Permite que você faça o comentário mesmo no caso de mesclagem não interativa.

git merge --edit --no-ff pode ser útil se você seguir o fluxo git com rebasing no ramo de desenvolvimento e mesclando-o sem avanço rápido.

Para versões atuais do Git (maio de 2020):

git rebase -i -r <parent>,

substitua no editor merge -C ...por merge -c ....

Isso abrirá a mensagem de confirmação no editor durante o rebaseamento, onde você pode alterá-la.

(Obrigado a VonC pela dica .)

O git rebase -i HEAD~5comando exibe o editor. Ele lista os commits especificados (neste caso, cinco deles). A primeira coluna contém pickpara cada confirmação. Apenas substitua pickpor rewordesse editor e salve + feche o editor. Então git irá aparecer o editor para cada commit onde você mudou pickpara reworde permitirá que você editar a mensagem de commit.