remove - git tags best practices

Iniciar un mensaje de confirmación git con un hashmark(#) (8)

Git trata las líneas que comienzan con # como líneas de comentarios al cometer. esto es muy molesto cuando se trabaja con un sistema de seguimiento de tickets y se intenta escribir el número del ticket al comienzo de la línea, por ejemplo

#123 salt hashed passwords

git simplemente eliminará la línea del mensaje de confirmación. ¿Hay alguna forma de escapar del hash? Probé / y ! , pero nada funciona. los espacios en blanco antes de # se conservan, por lo que tampoco son una solución funcional al problema.

Este comportamiento es parte del comportamiento predeterminado de "limpieza" de git commit . Si desea mantener las líneas que comienzan con # , puede usar un modo de limpieza alternativo.

P.ej

git commit --cleanup=whitespace

Si hace esto, debe tener cuidado de eliminar todas las # líneas que no desea que aparezcan en la confirmación.

Las respuestas aquí son buenas y detalladas, pero para un noob git como yo, personalizar las opciones de configuración de git no es tan obvio. Aquí hay un ejemplo para cambiar de # a ; para comentar personajes:

git config core.commentChar ";"

Eso es todo lo que necesitas hacer.

Puedes usar la opción de línea de comando -m :

git commit -m "#123 fixed"

Si está haciendo una rebase interactiva, cuando guarde su mensaje de confirmación sin nada (porque el # al principio lo ha hecho un comentario y, por lo tanto, se ha ignorado) git le mostrará qué hacer:

Aborting commit due to empty commit message. Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords This is most likely due to an empty commit message, or the pre-commit hook failed. If the pre-commit hook failed, you may need to resolve the issue before you are able to reword the commit. You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue

Entonces, solo enmiende el mensaje:

git commit --amend -m "#123 salt hashed passwords"

y continuar la rebase:

git rebase --continue

Tenga en cuenta que, desde git1.8.2 (febrero de 2013) , puede usar un carácter diferente al '' # '' para la línea comentada en el mensaje de confirmación.

Eso le permite usar '' # '' para la referencia de su número de error.

Varias líneas de "pistas" que Git da cuando le pide al usuario que edite los mensajes en el editor se comentan con '' # '' de forma predeterminada.
La variable de configuración core.commentChar se puede usar para personalizar este '' # '' a un carácter diferente.

En teoría, podría poner una palabra core.commentChar (varios caracteres), pero git 2.0.x / 2.1 será más estricto (Q3 2014).

Ver commit 50b54fd por Nguyễn Thái Ngọc Duy ( pclouds ) :

config: ser estricto en core.commentChar

No admitimos cadenas de comentarios (al menos no todavía). Y la codificación de caracteres de múltiples bytes también podría ser mal interpretada.
La prueba con dos comas se actualiza porque viola esto. Se agregó con el parche que introduce core.commentChar en eff80a9 (Permitir "char de comentario" personalizado - 2013-01-16). No me queda claro por qué se quiere ese comportamiento.

git 2.0.x / 2.1 (Q3 2014) agregará una selección automática para core.commentChar :
Ver commit 84c9dc2

Cuando core.commentChar es " auto ", el comentario com comienza con '' # '' como predeterminado, pero si ya está en el mensaje preparado, busque otro carácter en un pequeño subconjunto. Esto debería detener sorpresas porque git quita algunas líneas inesperadamente.
Tenga en cuenta que git no es lo suficientemente inteligente como para reconocer '' # '' como el carácter de comentario en plantillas personalizadas y convertirlo si el carácter final de comentario es diferente.
Piensa líneas ''#'' en plantillas personalizadas como parte del mensaje de confirmación. Así que no uses esto con plantillas personalizadas.

La lista de personajes candidatos para "auto" son:

# ; @ ! $ % ^ & | :

Eso significa que un comando como git commit -m ''#1 fixed issue'' fix git commit -m ''#1 fixed issue'' cambiará automáticamente el commentChar a '' ; '', porque'' # ''se usó en el mensaje de confirmación.

Todas mis confirmaciones comienzan con #issueNumber así que coloco este texto en mi vim .git/hooks/commit-msg :

NAME=$(git branch | grep ''*'' | sed ''s/* //'') echo "$NAME"'' ''$(cat "$1") > "$1"

Supongamos que tenemos la rama #15 y hacemos que el mensaje de confirmación add new awesome feature . Con este enfoque, el mensaje final de confirmación será #15 add new awesome feature .

Use un prefijo diferente para el número de boleto. O agregue una palabra al número del boleto, como "Bug # 42". O anteponer un único carácter de espacio a la línea; Si desea eliminar ese espacio en blanco, puede agregar un enlace de confirmación para eso.

Personalmente, preferiría que este tipo de manipulación de mensajes de confirmación no se realice por un gancho, ya que puede ser muy irritante cuando se dispara cuando no se desea. La solución más fácil es probablemente repensar el problema.

git commit --cleanup=scissors debe usar git commit --cleanup=scissors . Se agregó a Git v2.0.0 en 2014.05.21

de git commit --help

--cleanup=<mode> scissors Same as whitespace, except that everything from (and including) the line "# ------------------------ >8 ------------------------" is truncated if the message is to be edited. "#" can be customized with core.commentChar.