notifications Notificaciones

Marcar todas como leídas

Ver más

lightbulb_outline

15767 veces ha sido leído este artículo

Buenas Practicas en Commits de Git

Lo lees en 2 Min.

Un dia mientras navegaba por la web encontre un articulo (en realidad fueron varios), que hablaba sobre las BP en los mensajes de un commit. No entendia el por que era importante, ya que es algo simple y sencillo que la mayoria de las veces no prestamos atencion a como los ecribimos, generalmente solo escribimos algo como: "ya funciona x parte". Quede sorprendida cuando vi que tenian una estructura, estaban en ingles y demas, al momento de leerlo pense: "ah si un dia de estos lo aplicare..."

Mi preocupacion inicio el dia que me dijeron: "Pues pasame tu github, para ver tu trabajo", ni siquiera los nombres de los repos estaban "decentes". Asi que recurri a esta magica guia que en lo personal me ha ayudado bastante.

Commit Messages

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 mayuscula 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

Y... para terminar

Pueden revisar este articulo en ingles aqui.

Recomendaciones

Elixir el lenguaje de programación

Lo lees en 7 Min.

Elixir el nuevo lenguaje de programación. Quizás hayas oído hablar acerca de Elixir sin que te q...

 

Triggers Mysql

Lo lees en 1 Min.

En MySQL un trigger, también conocido como disparador (Por su traducción al español) es un conjun...

 

Pipes en Linux

Lo lees en 4 Min.

Pipes en linux Si eres usuario Linux/Unix es probablemente hayas oído hablar acerca de los pipes...

 

Qué es un Inode en UNIX

Lo lees en 3 Min.

Cuando administramos un servidor, es importante ir paso a paso conociendo detalles del sistema op...

 

favorite 1

Inicia sesión o Regístrate para poder agregar tu respuesta.