Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Un pequeño cambio en la forma que redactamos los mensajes al momento de hacer nuestros commit nos puede facilitar muchas cosas, desde el mantenimiento al código al ser más fácil identificar dónde/cuándo se realizo algún cambio, hasta la preparación de los despliegues al tener referencia de los Jiras trabajados.

Mensaje claro y descriptivo

Es importante recalcar que lo principal es lograr ser descriptivos en los mensajes de cada commit, ser claros al redactar los cambios realizados, tratando de contestar las siguientes preguntas.

  • ¿Qué se hizo?
  • ¿Por qué se hizo?
  • ¿Dónde se hizo?
  • ¿Se ha modificado algún parámetro de configuración en BDC? ¿Cuál es el cambio realizado?
  • ¿Se ha creado un nuevo parámetro de configuración? ¿Cuál es el nuevo parámetro?
  • ¿Se han modificado permisos? ¿Cuáles permisos se han modificado?
  • ¿Se han creado nuevos permisos? ¿Cuáles permisos se han modificado?


Formato
<tipo><opcional: símbolo ! que indica un cambio que puede afectar varias u otras funcionalidades>: <titulo>. (máximo 50 caracteres)

<resumen de las tareas realizadas, redactadas en tiempo presente> (sin límite de caracteres)

refs: <JIRA> (En caso de tener más de un JIRA involucrado, es posible realizar la separación de los JIRAS mediante ",")

<opcional: "BREAKING CHANGE" solo usar en conjunto con el símbolo ! de la primera línea>
Ejemplo
feat: Agregar funcionalidad.

Se agrega Controller/Request/Service para una funcionalidad determinada.

refs: PSA-12345

Más tipos

  • feat: nuevas funcionalidades para el usuario, no funcionalidades que sirven para el equipo de desarrollo.
  • fix: corrección de errores en la aplicación de cara al usuario, no correcciones que impliquen la construcción y/o distribución de los artefactos a desplegar
  • docs: cambios en la documentación
  • style: formateo del código, que no impliquen cambios directos al código y sus funcionalidades
  • refactor: refactorización del código y sus funcionalidades, renombrar variables, renombrar clases, etc.
  • test: agregar tests, refactorizar tests, sin que se realicen cambios al código y sus funcionalidades (adding missing tests, refactoring tests; no production code change)
  • chore: agregar o actualizar funcionalidades que ayuden al equipo de desarrollo y ayuden a la construcción y/o distribución de los artefactos a desplegar

Más ejemplos

Múltiples tareas realizadas del mismo tipo
fix: Agregar funcionalidad.

Se agrega Controller.
Se agrega mapeo de un campo.
Se modifica serialización para mostrar nuevo campo.

refs: PSA-12345
Múltiples tareas realizadas de distinto tipo
fix: Se corrige funcionalidad.

Se corrige validación.

refs: PSA-12345

feat: Se agrega funcionalidad.

Se agrega Controller.

refs: PSA-12346

test: Se agregan Tests.

Se agrega test de servicio

refs: PSA-12347

Importante

Lo ideal es realizar un commit por cada tipo de cambio que se está realizando, pero si no se hace por separado, lo mejor sería diferenciarlo en el mensaje del commit.

Breaking change
refactor!: Se refactoriza funcionalidad.

Se refactoriza servicio cambiando su constructor y modificando métodos.

refs: PSA-12345

BREAKING CHANGE
Una sola línea
style: Se actualiza imagen.
refs: PSA-12345

fix: Se corrige nombre de variable.
refs: PSA-12345

Referencias

https://www.conventionalcommits.org/en/v1.0.0/

https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

http://karma-runner.github.io/1.0/dev/git-commit-msg.html

  • No labels