Un día mientras navegaba por la web encontré un articulo (en realidad fueron varios), que hablaba sobre las BP en los mensajes de un commit. No entendía el por que era importante, ya que es algo simple y sencillo que la mayoría de las veces no prestamos atención a como los escribimos, generalmente solo escribimos algo como: “Cambios en el login”. Quedé sorprendido cuando vi que tenían una estructura, estaban en inglés y demás, al momento de leerlo pensé: “ah si un día de estos lo aplicaré…”

Mi preocupación inició el día que me dijeron: “Pues pásame tu github, para ver tu trabajo”, ni siquiera los nombres de los repos estaban “decentes”. Así que recurrí a esta mágica guía que en lo personal me ha ayudado bastante.


Sigue el GitFlow Workflow

  • master: En la rama máster se encuentran las releases estables de nuestro software. Esta es la rama que un usuario típico se descargará para usar nuestro software, por lo que todo lo que hay en esta rama debería ser funcional. Sin embargo, puede que las últimas mejoras introducidas en el software no estén disponibles todavía en esta rama.
  • develop: En esta rama surge de la última release de master. En ella se van integrando todas las nuevas características hasta la siguiente release.
  • feature-X: Cada nueva mejora o característica que vayamos a introducir en nuestro software tendrá una rama que contendrá su desarrollo. Las ramas de feature salen de la rama develop y una vez completado el desarrollo de la mejora, se vuelven a integrar en develop.
  • release-X: Las ramas de release se crean cuando se va a publicar la siguiente versión del software y surgen de la rama develop . En estas ramas, el desarrollo de nuevas características se congela, y se trabaja en arreglar bugs y generar documentación. Una vez listo para la publicación, se integra en master y se etiqueta con el número de versión correspondiente. Se integran también con develop, ya que su contenido ha podido cambiar debido a nuevas mejoras.
  • hotfix-X: Si nuestro código contiene bugs críticos que es necesario parchear de manera inmediata, es posible crear una rama hotfix a partir de la publicación correspondiente en la rama master. Esta rama contendrá únicamente los cambios que haya que realizar para parchear el bug. Una vez arreglado, se integrará en master, con su etiqueta de versión correspondiente y en develop.


Mensajes de commit

Los mensajes de commit son una herramienta muy útil para el desarrollo de software, ya que nos permiten encontrar cambios concretos en la historia de nuestro repositorio. No obstante, muchas veces no les prestamos toda la atención que se merecen, y escribrimos mensajes de commit que son de muy poca ayuda para nuestros compañeros y para nuestros yo del futuro. Esta sección aporta buenas prácticas a seguir para aprovechar los mensajes de commit al máximo.


Escribe mensajes de commit claros y concisos

Las siguentes reglas de estilo harán que tus mensajes de commit sean más claros y concisos:

  • Los mensajes de commit tienes dos partes principales: un asunto y un mensaje (como los correos electrónicos). Si el contenido del commit se puede explicar en el asunto, no es necesario incluir un mensaje. Ambas partes deben ir separadas por una línea en blanco.
  • La línea de asunto no debería extenderse más de 50 caracteres, y el cuerpo del mensaje debería tener una extensión máxima (por línea) de 72 caracteres. Esto ayuda a su visualización en distintas plataformas y dispositivos.
  • La línea de asunto debe comenzar con letra mayúscula y terminar sin punto. Piensa, por ejemplo, en el asunto de un correo electrónico.
  • Usa el imperativo en el mensaje de commit. Internamente Git usa el imperativo en los mensajes que genera. Por ejemplo, Merge branch 'feature-refactor' tras fusionar la rama feature-refactor. Para mantener la coherencia de todos los mensajes de commit, adoptaremos la convención de Git de usar el imperativo.


Usa el mensaje de commit para aportar contexto y explicar el por qué detrás de un cambio.

La principal utilidad de un mensaje de commit no es explicar cuáles son los cambios que realizará ese commit, ya que se pueden consultar en el diff del commit. La principal utilidad del mensaje de commit es explicar el por qué detras de esos cambios.

Por tanto, cuando el por qué de un cambio no quede suficientemente claro con el asunto y el diff del commit, usaremos el cuerpo del mensaje de commit para aportar un contexto y un por qué a dichos cambios. Esto es especialmente importante si existen soluciones alternativas a la implementada en el commit, ya que así los futuros mantenedores del código pueden saber por qué se elegió esa solución frente a otras alternativas.

Si el cambio realizado, además, puede tener consecuencias inesperadas o efectos secundarios en el resto del código, es importante especificarlo también en el mensaje de commit.


Estructura del Mensaje

El mensaje de un commit consiste en 3 diferentes partes separadas por una linea en blanco: el titulo, un cuerpo opcional y un pie opcional. Algo como lo siguiente:

type: subject 

body 

footer

El titulo consiste en el tipo y asunto del mensaje.


Type / Tipo

El tipo es contenido en el titulo y puede ser de alguno de los siguientes casos:

feat: Una nueva caracteristica.

fix: Se soluciono un bug.

docs: Se realizaron cambios en la documentacion.

style: Se aplico formato, comas y puntos faltantes, etc; Sin cambios en el codigo.

refactor: Refactorizacion del codigo en produccion.

test: Se añadieron pruebas, refactorizacion de pruebas; Sin cambios en el codigo.

chore: Actualizacion de tareas de build, configuracion del admin. de paquetes; Sin cambios en el codigo.


Subject / Asunto

El asunto no debe contener mas de 50 caracteres, debe iniciar con una letra mayúscula y no terminar con un punto. Debemos ser imperativos al momento de redactar nuestro commit, es decir hay que ser objetivos y muy importante tenemos que acostumbrarnos a escribirlos en Ingles esto es una de las mejores practicas que podemos tener en nuestros commits.

Cuando hablo de ser imperativos hago referencia a este sencillo ejemplo: usar change en lugar de “changed” o “changes”.


Body / Cuerpo

No todos los commits son lo suficientemente complejos como para necesitar de un cuerpo, sin embargo es opcional y se usan en caso de que el commit requiera una explicacion y contexto. Utilizamos el cuerpo para explicar el ¿Que y Porque? de un commit y no el ¿Como? Al escribir el cuerpo, requerimos de una linea en blanco entre el titulo y el cuerpo, ademas debemos limitar la longitud de cada linea a no mas de 72 caracteres.


Footer / Pie

El pie es opcional al igual que el cuerpo, pero este es usado para el seguimiento de los IDs con incidencias.

Ejemplo de un Commit Message

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72 
characters or so. In some contexts, the first line is treated as the 
subject of the commit and the rest of the text as the body. 

The blank line separating the summary from the body is 
critical (unless you omit the body entirely); 
various tools like `log`, `shortlog` and `rebase` can get 
confused if you run the two together. 

Explain the problem that this commit is solving. 
Focus on why you are making this change as oppose
to how (the code explains that). 

Are there side effects or other unintuitive consequenses of this change?
Here's the place to explain them.
Further paragraphs come after blank lines.

- Bullet points are okay, too 
- Typically a hyphen or asterisk is used for the bullet, preceded by a 
single space, with blank lines in between, but conventions vary here

If you use an issue tracker, put references to them at the bottom, like this:

Resolves: #123 
See also: #456, #789

Hacer código en equipo no es nada fácil, pero con las herramientas que tenemos actualmente es mucho más llevadero que antaño.

Depende de nosotros usarlas para crear un entorno de trabajo útil o un verdadero infierno de conflictos y merges innecesarios.

git commit -a