Git-notes

Con git notes puedes añadir una "nota" a un commit. También puede agregarlos a otros objetos Git, pero vamos a centrarnos en confirmaciones ya que eso es lo que la pregunta es sobre.

Una nota es un objeto Git, y en principio puede ser "lo que sea" (arbitrario datos). Pero nos centraremos en algo simple y textual para nuestros propósitos.

Ejemplo: review id

La pregunta menciona id de revisión, así que inventemos alguna manera de representar tal cosa. No lo sé lo que realmente parecen ID de revisión, pero espero que lo siguiente sea sensato:

Review-id: 42

Así que esto es efectivamente un par clave-valor. Vamos a añadir la cadena anterior a el commit actual:

git notes add -m "Review-id: 42"

Si ejecuta git log la nota se mostrará en línea†:

Author: Victor Version Control <[email protected]>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

Otro ejemplo

Por supuesto, puede agregar más "subnotas" a esta nota (nos quedaremos con la sintaxis simple key: value, un valor por línea). Por ejemplo, si se enteró tres meses después de que la comisión mensaje tiene algo mal, solo añade la corrección a la nota:

git notes append -m "Errata: It was actually feature y."

git log:

Author: Victor Version Control <[email protected]>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

    Errata: It was actually feature y.

Utilizamos git notes append con el fin de añadir fácilmente estos datos adicionales a la nota. También puede usar git notes edit para editar el archivo directamente.

Por supuesto, dado que una nota de Git es solo un único archivo mutable, puede ejecutar en conflictos de fusión. Para hacerlo menos probable, puedes:

1. Apégate a datos simples como los anteriores (una clave-valor por línea).
2. Usar fusión especial estrategias; ver man git-notes, sección " Notas merge strategies".

Visibilidad

El OP preguntó: {[46]]}

> ¿Puedo hacer que ciertas etiquetas sean invisibles?

Por defecto, git log solo muestra una nota, a saber .git/refs/notes/commits. commits es solo una nota en el espacio de nombres. Tal vez quieras que los problemas estén en su propio espacio de nombres:

git notes --ref=issues add -m "Fixes: #32"

Ya que esto se almacena en .git/refs/notes/issues y no en .git/refs/notes/commits, "Correcciones: #32" no aparecerá cuando se ejecuta git log. Así que usted ha hecho efectivamente tales notas invisible por defecto.

Si quieres que se muestre, pasa --notes=issues a git log:

$ git log --notes=issues
Author: Victor Version Control <[email protected]>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

Pero ahora .git/refs/notes/commits están ocultos. Que uno puede ser fácilmente incluido también:

$ git log --notes=issues --notes=commits
Author: Victor Version Control <[email protected]>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

Notes:
    Review-id: 42

    Errata: It was actually feature y.

Hay variables para configurar qué notas se muestran por defecto; ver man git-config.

Beneficios en comparación con los mensajes de confirmación

Por supuesto, los metadatos se pueden registrar directamente en el mensaje de confirmación. Pero los mensajes de confirmación son inmutables, por lo que cambiarlos realmente significa hacer un todo nuevo commit, con todas las consecuencias que eso conlleva. Git-notes, por otro lado, es mutable, por lo que siempre puede revísalos. Y cada modificación de una nota es, por supuesto, la versión controlable. En nuestro caso, para .git/refs/notes/commits:

$ git log refs/notes/commits
Author: Victor Version Control <[email protected]>
commit 9f0697c6bbbc6a97ecce9834d4c9afa0d668bcad
Date:   Tue Nov 8 21:13:52 2016 +0100

    Notes added by 'git notes append'

commit b60997e49444732ed2defc8a6ca88e9e21001a1d
Author: Victor Version Control <[email protected]>
Date:   Tue Nov 8 21:10:38 2016 +0100

    Notes added by 'git notes add'

Compartiendo notas

Sus notas no se comparten por defecto; tiene que hacerlo explícitamente. Y en comparación con otros árbitros, compartir notas no es muy fácil de usar. Tenemos para usar la sintaxis refspec:

git push refs/notes/*

Lo anterior empujará a todos de sus notas a su control remoto.

Parece que obtener notas es un poco más complicado; puede hacerlo si usted especifica ambos lados de la refspec:

git fetch origin refs/notes/*:refs/notes/*

Así que eso definitivamente no es conveniente. Si tienes la intención de usar Git-notes regularmente, es probable que desee configurar su gitconfig para obtener siempre notas:

[remote "origin"]
    …
    fetch = +refs/notes/*:refs/notes/*

(Fuente: https://git-scm.com/blog/2010/08/25/notes.html )

Carry over notes on rewrites{[50]]}

Git tiene el inconveniente por defecto que las notas no se transfieren cuando un commit se reescribe. Así que si por ejemplo rebase una serie de confirmaciones, las notas no transferir a las nuevas confirmaciones.

La variable notes.rewrite.<command> está establecida por defecto en true, por lo que uno podría supongamos que las notas son arrastradas. Pero el problema es que la variable notes.rewriteRef, que determina qué notas serán arrastradas, no tiene valor vaule. Para establecer este valor para que coincida con todas las notas, ejecute el siguiente:

git config --global notes.rewriteRef "refs/notes/*"

Ahora todas las notas se transferirán al hacer operaciones de reescritura como git rebase.

Transferir notas a través de parches de correo electrónico

Si está utilizando git format-patch para formatear sus cambios para que se envíen como correos electrónicos, y tiene algunos metadatos almacenados como notas de Git, puede pasar el --notes opción a git format-patch para anexar las notas al borrador del correo electrónico.

† " Este es el valor predeterminado para git log [when] cuando no hay --pretty, --format, o --oneline opción dada en la línea de comandos."- man git-log, git versión 2.10.2