Conventional Commit

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

Los commit sirven para manetener un historial de los cambios que se han producio en un proyecto.

Cada persona tiene una forma de nombrar los commits y esto no en correcto a la hora de trabajar en equipo.

Para evitar este problema se ha propueso utilizar el estandar de conventional commits:

Esto es tanto muy util para las personas como para las máquinas. gracias a que los commits siempre van a estar descritos de una forma estandar se pueden generar herramientas que automaticen acciones basandose en la estructura de los commits (herramientas de análisis del historico de cambios commits). cambios automaticos en ficheros control de versiones automatico

##Herramientas que aseguran el uso de convential commit (commitlint)[https://github.com/conventional-changelog/commitlint] problema deberiamos de ejecutar esta herramienta de forma manual antes de subir el commit al repositorio

solucion hasky https://github.com/typicode/husky Es una herramienta de configurador de hooks de git. Por ejemplo antes de hacer un push ejecutar los test

Ejemplo

<type>[optional scope]: <description>
<BLANK LINE>
[optional body]
<BLANK LINE>
[optional footer(s)]

###Type Must be one of the following:

*build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) *ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) *docs: Documentation only changes *feat: A new feature *fix: A bug fix *perf: A code change that improves performance *refactor: A code change that neither fixes a bug nor adds a feature *style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) *test: Adding missing tests or correcting existing tests