 |
Al trabajar con sistemas de control de versiones como git se empieza a generar una duda, que se tiene que escribir en el mensaje del commit, que estructura o que información se debe ingresar?
A continuación se anexan algunas definiciones que han venido definiendo comunidades
Conventional commits define la siguiente estructura
<tipo>[ámbito opcional]: <descripción>
[cuerpo opcional]
[nota de pie opcional]
Los tipos de commits que se definen son los siguientes
| feat | Caracteritica nueva | Caracteristicas | |
| fix | Correccion de error | Correccion de errores | |
| docs | Solo se modifica documentacion | Documentacion | |
| style | Cambios en el estilo de codificacon (Python, Pylint, Javascript, ESLint) | Estilos | |
| refactor | Cambio en el codigo que no corrige errores ni agrega nuevas características | Refactorizacion de codigo | |
| perf | Cambio en el codigo que mejora el rendimiento | Mejoras de rendimiento | |
| test | Se agregan o corrigen pruebas de codigo | Pruebas | |
| build | Cambios que afectan a la forma en la que se construye o empaqueta (ejemplos scopes: gulp, broccoli, npm) | Build | |
| ci | Cambios en el sistema de integracion continua (ejemplos scopes: Travis, Circle, BrowserStack, SauceLabs) | Integracion continua | |
| chore | Otros cambios que no modifican codigo base o pruebas (ejemplo, mantenimiento) | chore | |
| rever | Revierte |
Dentro del cuerpo del mensaje tambien se debe especificar cuando se realizan cambios que puede romper la compatibilidad, para esto se debe especificar de la siguiente forma
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files