Skip to content

Conventional Commit

Jump to bottom
Jose Manuel Delgado Trueba edited this page Dec 11, 2020 · 6 revisions

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. a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
  • fix: A bug fix. a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
  • 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
  • BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

Scope The scope should be the name of the package affected

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Subject The subject contains a succinct description of the change:

https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

Clone this wiki locally