Etiquetado de posts de compromiso y sets de cambios

Estoy buscando una solución, labelr sets de cambios en posts de compromiso.

Para mí, una "label" es algo así como:

  • limpieza del código
  • cambio visible del usuario
  • modifica la estructura de la database (ALTER TABLE)
  • Cambio de documentation

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

Quiero que esto responda preguntas como esta:

  • Si actualizo un sistema, ¿qué cambios están visibles para el cliente o solo se trata de una actualización de mantenimiento?
  • ¿El esquema de la database ha cambiado entre dos versiones?

Fondo:

Hasta ahora uso unison para sincronizar entre DEV, TEST y el 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: quiero ver cambios entre TEST y PROD. No quiero ver el código fuente cambia, pero los posts de confirmación. Pero a veces hay hasta 100 commits. Aquí quiero un filter para excluir cambios sin importancia.

Me gusta usar las siguientes tags:

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 (eg, changes in the ignore list) TEST related to test code only. 

Esta label siempre es lo primero en el post de confirmación y luego sigue una breve descripción y / o la identificación del problema del sistema de seguimiento de problemas, si existe.

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

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

También me gusta combinar esas tags en un post de compromiso cuando corresponda. Por ejemplo, "TEST DOC setup of test foo".

Con una label DB adicional para la database, puede realizar un seguimiento de los cambios relacionados con la database.

La mayoría de las veces estoy usando el sistema de tags de Typo3: http://wiki.typo3.org/CommitMessage_Format_(Git)

Utiliza tags en posts de compromiso como este: [TAG] Short message Por supuesto, siempre aparece un número de problema para el seguimiento de problemas. Estamos usando JIRA por lo que se convertirá en algo como esto: [TAG] JIRA-123 Short message

Etiquetas Typo3:

Las posibles tags son:

  • [FUNCIÓN]: 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 twig "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, por ejemplo, limpieza del coding style.
  • [API]: una API ha cambiado, se han agregado o eliminado methods o classs; las firmas de methods o los types de devolución han cambiado. Esto solo se refiere a la API pública de TYPO3.

Además, pueden agregarse otros indicadores bajo 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 security. Esta label es utilizada por el Equipo de Seguridad, en caso de que encuentre problemas de security, por favor siga siempre primero en contacto con el Equipo de Seguridad.

Descripciones de tema de ejemplo:

  • [BUGFIX] Lanza HttpStatusExceptions en tslib_fe
  • [BUGFIX] [SECURITY] Vulnerabilidad de inyección SQL en declaraciones preparadas
  • [FUNCIÓN] [CONF] Agregar opción para ocultar el cuadro de búsqueda BE en la list mod
  • [!!!] [FUNCIÓN] Mueva la edición avanzada de frontend a TER
  • [!!!] [TAREA] Eliminar t3lib_sqlengine
  • [!!!] [API] Elimina el método obsoleto networkingirect () de t3lib_userAuth
  • [API] Crea una jerarquía de excepciones para excepciones de estado HTTP

Prefiero asignar cada set 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 set de cambios. Después de seleccionar un problema, la descripción del problema se coloca automáticamente en el post del set de cambios. Pueden seguirse en el futuro y también se informarán en su rastreador de problemas.