Haciendo commits atómicos

Por suerte o por desgracia, según el punto de vista con el que se mire, es habitual que pase cierta cantidad de tiempo revisando pull request.

Una de las prácticas que más hecho de menos, cuando no me lo encuentro o por el contrario más agradezco cuando si me lo encuentro, son los commits atómicos.

Commits atómicos

La palabra átomo significa la partícula más pequeña posible de materia, indivisible.

Si al utilizar git seguimos la estrategía de crear una rama nueva por cada feature a crear o por cada bug a resolver, un commit atómico se correspondería con cada una de las subtareas en las que se podría desglosar la tarea principal.

Estas subtareas es posible que signifique cambiar o crear un fichero o varios, lo importante es darle al commit un valor semántico.

¿Porque commits atómicos?

Los commits atómicos tienen pincipalmente dos ventajas:

• Code reviews más fáciles, independientemente de que el code review se haga a través de un pull request o con el compañero sentado al lado, es mucho más fácil de entender el historial de commits si están creados desde un punto de vista semántico y atómico que si están creados desde un punto de vista subjetivo a solución aplicada técnicamente.

• Más fácil de revertir, imagina que después de solucionar un bug, no lo hemos solucionado correctamente o incluso hemos introducido otro, en este caso una posible solución es revertir la solución que habíamos aplicado. Si no existe un commit que indique claramente el punto donde se introdujo esa solución va a ser complicado de revertir y no quedará más remedio que bucear por el código.

• Moverte por el historial de commits es más fácil, hay diferentes motivos por lo que puede ser interesante moverte a un punto del historial de commits en concreto. En este caso no hay nada peor que hacer check out de un commit y que el proyecto no compile o le falte algo a cierta funcionalidad para estar completa y que esté en otros commits mezclado con otras funcionalidades.

Sentido común

Es cierto que hay parte subjetiva en todo esto y es posible que haya diferentes criterios entre varias personas, lo importante es aplicar el sentido común y terner una estrategía base consencuada entre los componentes del equipo aceptando estas pequeñas diferencias de criterio.

Sin embargo hay situaciones que son dificiles de poder defender, por ejemplo:

• Un pull request con 1 solo commit y muchos ficheros moficados.
• Un pull request con 1 commit por cada fichero modificado.

Aunque puedan parecer casos muy exagerados, son casos que me he encontrado revisando pull request más veces de las que me gustaría y no es fácil de lidiar.

El hábito hace al monje

Si durante nuestro día a día vamos realizando commits para cada una de esas subtareas que vamos completando es más fácil conseguir tener un historial de commits atómicos.

Todo lo contrario sucede si caemos en prácticas de hacer commit al final del día o según me apetece.

Ejemplo

Si un diseñador nos manda una serie de cambios considerables a realizar en varias pantallas, una posible estrategia sería crear una rama por cada una de las pantallas y un commit por cada cambio que nos piden dentro de cada pantalla, veamos como podría quedar:

• Pantalla de login
  rama: Design-login_screen
  commits:

  • Fix bug in logo padding
  • Fix buttons width in landscape
  • ...

• Pantalla de perfil de usuario
  rama: Design-profile_screen
  commits:

  • Change fullname to bold
  • Change background screen
  • ...

• Pantalla de spash
  rama: Design-spash_screen
  commits:

  • Change logo
  • Change progress bar style
  • ...

De esta forma, independientemente del número de ficheros que tengas que cambiar para realizar un cambio dentro de una pantalla la persona que revisa lo va a tener mucho más fácil porque existe una equivalencía entre la revisión del diseñador y el historial de commits de la solución aplicada.

Conclusiones

Hemos visto en que consisten los commits atómicos y que ventajas nos aportan.

Es importante tener presente que esos commits que estamos generando tienen una utilidad en el futuro.

El historial de commits de una rama o de un pull request debería ser como el índice de un libro o un documento, donde aparecen los títulos de las subtareas que te vas a encontrar en el código.