Git: ¿Cómo editar / reformular el mensaje de un commit de fusión?

148

¿Cómo edito o reformulo el mensaje de una confirmación de fusión?

git commit --amendfunciona si es el último commit realizado ( HEAD), pero ¿y si viene antes HEAD?

git rebase -i HEAD~5 no enumera las confirmaciones de fusión.

ma11hew28
fuente

Respuestas:

207

Si agrega la --preserve-mergesopción (o su sinónimo, -p) al git rebase -icomando, git intentará preservar las fusiones al rebasear, en lugar de linealizar el historial, y también debería poder modificar las confirmaciones de fusión:

git rebase -i -p HEAD~5
Mark Longair
fuente
1
He hecho esto, pero después de hacer mis cambios y trato de impulsar mis cambios, obtengo esto! [rejected] HEAD -> master (non-fast-forward)error: failed to push some refs to
Marc
1
intente ejecutar git push -f y luego su rama de origen. Esto debería funcionar. Tuve el mismo problema, por alguna razón, esto es un artefacto de rebase porque básicamente lo que sucedió es que después de rebasar terminaste con un cobertizo separado, por lo que la fuerza debería arreglar eso y empujar todo.
Radu Comaneci
11
@Marc Esto sucede porque modificó las confirmaciones que ya envió. Se considera una mala práctica forzar la inserción en un servidor, ya que puede desincronizarlo completamente a usted y a sus compañeros de trabajo. Bueno, si estás solo no debería ser un problema.
ibizaman
¿Dónde HEAD~5está el padre de la confirmación que desea modificar (generalmente sha1 ^)?
Gabriel Devillers el
2
--preserve-mergeses ahora--rebase-merges
OrangeDog
32

Tenga en cuenta que, al iniciar git1.7.9.6 (y git1.7.10 +), git mergesiempre activará el editor , para que pueda agregar detalles a una fusión.

" git merge $tag" para fusionar una etiqueta anotada siempre abre el editor durante una sesión de edición interactiva. La serie v1.7.10 introdujo una variable de entorno GIT_MERGE_AUTOEDIT para ayudar a los scripts anteriores a rechazar este comportamiento, pero la pista de mantenimiento también debería admitirlo.

También presenta una variable de entorno GIT_MERGE_AUTOEDITpara ayudar a los scripts anteriores a rechazar este comportamiento.

Ver " Anticipando Git 1.7.10 ":

Recientemente, en una discusión sobre la lista de correo de Git , Linus admitió (y acepté) que este fue uno de los errores de diseño que cometimos al principio de la historia de Git.
Y en 1.7.10 y posteriores, el comando git merge que se ejecuta en una sesión interactiva (es decir, tanto su entrada estándar como su salida estándar conectada a un terminal) abrirá un editor antes de crear una confirmación para registrar el resultado de la fusión, para dar el usuario tiene la oportunidad de explicar la fusión, tal como lo hace el comando git commit que ejecuta el usuario después de resolver una fusión en conflicto.

Linus dijo:

Pero realmente no me importa mucho cómo funciona realmente: mi problema principal es que git hace que sea demasiado fácil tener mensajes de fusión erróneos.
Creo que parte de eso es una idiotez aún más simple: ni siquiera activamos el editor por defecto para una "fusión de git", pero lo hacemos para una " git commit".
Ese fue un error de diseño, y significa que si realmente desea agregar una nota a una fusión, debe hacer un trabajo adicional. Entonces la gente no
.


Tenga en cuenta que, antes de Git 2.17 (Q2 2018), " git rebase -p" destrozó los mensajes de registro de una confirmación de fusión, que ahora está corregida.

Ver commit ed5144d (08 de febrero de 2018) por Gregory Herrero (``) .
Sugerido por: Vegard Nossum ( vegard) y Quentin Casasnovas ( casasnovas) .
(Fusionada por Junio ​​C Hamano - gitster- en commit 8b49408 , 27 feb 2018)

rebase -p: corrige un mensaje de confirmación incorrecto al llamar git merge.

Dado que commit dd6fb00 (" rebase -p: cita entre arreglos al llamar git merge", enero de 2018, Git 2.16.0-rc2), el mensaje de confirmación de la confirmación de fusión que se está volviendo a redactar se pasa al comando de combinación mediante una ejecución de subshell ' git rev-parse --sq-quote'.

Se necesitan comillas dobles alrededor de esta subshell para que se mantengan nuevas líneas para el git mergecomando.

Antes de este parche, siguiente mensaje de combinación:

"Merge mybranch into mynewbranch

Awesome commit."

se convierte en:

"Merge mybranch into mynewbranch Awesome commit."

después de a rebase -p.


Con Git 2.23 (Q2 2019), una " merge -c" instrucción durante " git rebase --rebase-merges" debería darle al usuario la oportunidad de editar el mensaje de registro, incluso cuando no sea necesario crear una nueva fusión y reemplazar la existente (es decir, avanzar rápidamente en su lugar) ), pero no.
Que ha sido corregido.

Ver commit 6df8df0 (02 de mayo de 2019) por Phillip Wood ( phillipwood) .
(Fusionada por Junio ​​C Hamano - gitster- en commit c510261 , 13 jun 2019)

VonC
fuente
16

Otra buena respuesta usando solo 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

o un comando de rebase final mejor (más correcto):

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

Por cierto, el uso de los comandos primitivos podría tener la buena "característica" de no consumir demasiada CPU y hacer que espere un tiempo desconocido hasta que Git termine de pensar en la lista de confirmaciones que deben modificarse en el caso de git rebase -p -i HEAD^^^^(un comando que resultaría en ¡una lista de solo 4 últimas confirmaciones con la fusión como la última en mi caso en mi caso tomó alrededor de 50 segundos!).

rev imz - Ivan Zakharyaschev
fuente
2
Esto es realmente útil, ahórrame un poco de tiempo. Mi compañía bloquea algunos mensajes de confirmación en el repositorio, lo cual es fácil con --amend o con comandos de rebase pero: Gran problema si fusionamos alguna rama en la suya, hacemos algo de confirmación e intentamos empujar, el mensaje de fusión predeterminado de git está bloqueado ( esto debería solucionarse, lo sé), lo que nos obliga a cambiar ese mensaje. Hasta esta respuesta, he intentado muchas cosas para cambiar un mensaje de fusión entre un historial de confirmaciones sin éxito.
Giovanni Silva
2

git merge --edit
Le permite dar el comentario incluso en caso de fusión no interactiva.

git merge --edit --no-ff puede ser útil si sigue el flujo de git con rebase en la rama de desarrollo y se fusiona sin avance rápido.

Do-do-new
fuente
2

Para las versiones actuales de Git (Mai 2020):

git rebase -i -r <parent>,

luego reemplace en el editor merge -C ...con merge -c ....

Esto abrirá el mensaje de confirmación en el editor durante el rebase, donde puede cambiarlo.

(Gracias a VonC por la pista ).

Eugen Labun
fuente
0

El git rebase -i HEAD~5comando abre el editor. Enumera las confirmaciones especificadas (en este caso, cinco de ellas). La primera columna contiene pickpara cada confirmación. Simplemente reemplace pickcon reworden ese editor y guarde + cierre el editor. Entonces git emergerá el editor para cada confirmación, donde ha cambiado picka rewordy le permitirá editar el mensaje de confirmación.

ChrisD
fuente
66
Esto no funciona para una confirmación de fusión a menos que también agregue -pal git rebasecomando.
Paul Price
44
gran respuesta si fuera una pregunta diferente
doz87