Etiquetado de mensajes de compromiso y conjuntos de cambios

Question

Estoy buscando una solución para etiquetar conjuntos de cambios en los mensajes de confirmación.

Para mí una "etiqueta" es algo así como:

• código limpiar
• usuario cambio visible
• modifica la estructura de base de datos (ALTER TABLE)
• cambio de documentación

Hasta ahora uso SVN, pero quiero cambiar a git. Si hubiera un estándar, muchas herramientas como trac, redmine, ... podrían usar esto.

Quiero que esto responde a preguntas como ésta:

• Si actualizo un sistema, ¿qué cambios son visibles para el cliente, o es simplemente una actualización maintance?
• ¿El esquema de la base de datos ha cambiado entre dos versiones?

Antecedentes:

Hasta ahora uso unísono para sincronizar entre DEV, TEST y sistema PROD. Pero unison no sabe nada sobre la gestión de versiones (que es SVN en el panel). Quiero cambiar a git. Y quiero ver rápido, ¿cuáles son los cambios?

Ejemplo: Deseo ver cambios entre TEST y PROD. No quiero ver el código fuente cambia, pero los mensajes de confirmación. Pero a veces hay hasta 100 commits. Aquí quiero un filtro para excluir cambios sin importancia.

Answer 1

me gusta usar las siguientes etiquetas:

ADD adding new feature 
FIX a bug 
DOC documentation only 
REF refactoring that doesn't include any changes in features 
FMT formatting only (spacing...) 
MAK repository related changes (e.g., changes in the ignore list) 
TEST related to test code only. 

Esta etiqueta es siempre el primero que en el mensaje de confirmación y luego seguido por una breve descripción y/o la emisión-id del sistema de seguimiento de problemas, si existiera.

Utilizo esas etiquetas con svn y git y hasta ahora las encontré muy convenientes.

Para responder a su edición: Es por eso que me gustan esas etiquetas de confirmación. Es inmediatamente visible si la confirmación cambia el comportamiento o no. Si su esquema de base de datos cambia regularmente o si estos cambios son muy importantes para usted, puede introducir una etiqueta para eso.

También me gusta combinar esas etiquetas en un mensaje de confirmación cuando corresponda. Por ejemplo, "TEST DOC setup of test foo".

Con una etiqueta DB adicional para la base de datos, puede realizar un seguimiento de los cambios relacionados con la base de datos.

Answer 2

Prefiero asignar cada conjunto de cambios con un problema en mi rastreador de problemas. Usando rastreadores de problemas conocidos como jira, es posible seleccionar el problema que se resuelve en un conjunto de cambios. Después de seleccionar un problema, la descripción del problema se coloca automáticamente en el mensaje del conjunto de cambios. Pueden seguirse en el futuro y también se informarán en su rastreador de problemas.

Answer 3

mayor parte del tiempo estoy usando el sistema de etiquetas de Typo3: http://wiki.typo3.org/CommitMessage_Format_(Git)

Utiliza las etiquetas en los mensajes de confirmación como este: [TAG] Short message Por supuesto que siempre pop en un número de emisión de seguimiento de problemas. Estamos utilizando JIRA por lo que se convertirá en algo como esto: [TAG] JIRA-123 Short message

etiquetas Typo3:

etiquetas posibles son:

• [especiales]: Una nueva característica (también pequeñas adiciones). Lo más probable es que sea una característica adicional, pero también podría eliminarse. Esto solo puede ocurrir en la rama "principal" de v4, porque no se permiten nuevas funciones en las sucursales más antiguas. Las excepciones a esto deben discutirse caso por caso con los administradores de versiones correspondientes.
• [BUGFIX]: una solución para un error.
• [TAREA]: Todo lo que no esté cubierto por las categorías anteriores, p. limpieza de estilo de codificación.
• [API]: una API ha cambiado, los métodos o las clases se han agregado o eliminado; las firmas de métodos o los tipos de devolución han cambiado. Esto solo se refiere a la API pública de TYPO3.

Adicionalmente otras banderas podrían añadirse en ciertas circunstancias:

• [!!!]: Rompiendo el cambio. Después de este parche, algo funciona de manera diferente que antes y el desarrollador de usuario/administrador/extensión tendrá que cambiar algo. Solo debería ocurrir en "maestro".
• [WIP]: Work In Progress. Esta bandera se eliminará una vez que esté disponible la versión final de un cambio. Los cambios marcados como WIP nunca se fusionan.
• [SEGURIDAD]: visualiza que un cambio soluciona un problema de seguridad. Esta etiqueta es utilizada por el Equipo de Seguridad, en caso de que encuentre problemas de seguridad, por favor siga siempre primero en contacto con el Equipo de Seguridad.

descripciones Ejemplo tema:

• [Bug arreglado] Throw HttpStatusExceptions en tslib_fe
• [Arreglado] [SEGURIDAD] vulnerabilidad de inyección SQL en declaraciones preparadas
• [especiales] [CONF] Añadir opción para ocultar el cuadro de búsqueda BE en la lista mod
• [!!!] [FUNCIÓN] Mover la edición avanzada de frontend a TER
• [!!!] [TAREA] Eliminar t3lib_sqlengine
• [!!!] [API] Retire redirección método obsoleto() desde t3lib_userAuth
• [API] Crear una jerarquía de excepciones de excepciones de estado HTTP