Dependiendo del uso que le demos a git podemos obtener una serie de información bastante jugosa y vitaminada.

En este post vamos a ver qué información jugosa podemos obtener, qué hace falta para tener esa información y cómo obtener esa información.

Recordad siempre tomar el zumo rápido… que se le van las gitaminas 🍊 .

Contexto.

Estamos más que acostumbrados a usar git, es una herramienta que, sin ella, estaríamos condenados a la tortura de tener carpetas con nombres como:

  • Versión final.
  • Versión final, de verdad.
  • Versión final final.
  • Versión final gold plus.
  • Versión requetefinal gold plus god level terminado.

Y para lo que es la gestión, es horrible. Por eso git es tan maravilloso y bonito, tan solo hay que ver el uso y su extensión alrededor del mundo. Ya sea en forma local, gestionando tus proyectos o subiéndolos a la nube utilizando algún servicio como GitLab o Github.

Pero git no sólo tiene por qué servir para controlar versiones de nuestro software, también nos puede dar información útil.

Qué información.

Si te digo que con git podrías saber si un desarrollo va bien, ¿Qué me dirías? O mejor, te podría llegar a decir:

  • si el equipo trabaja bien.
  • Si rinde como toca.
  • Si los desarrollos salen a tiempo (o no).
  • Si hay problemas de organización o gestión.
  • Etc, el límite está en tu imaginación.

El cómo lo veremos pronto pero antes quiero que tengas claro que su misión principal es la de gestionar un proyecto, yo te voy a dar un giro de tuerca a lo que es git aprovechando una herramienta y la buena formación de tus empleados.

Qué hace falta.

No mucho, la verdad. Commits y seguir unas directrices de diseño y usar una herramienta de consola (aunque es opcional).

Vayamos con la estructura: ​​

Estructura de ejemplo.

Lo primero que vemos son secciones:

  • Emoji.
  • Scope.
  • Tipo.
  • Titulo.

Emoji.

Nos da una información rápida y visual sobre lo que contiene el commit. En este ejemplo, tenemos el emoji de un bug por lo que se entiende que va a tratar de un error en el código.

Scope.

Hacía donde apunta este commit, este campo es para relacionar el commit con algún identificador de ticket o incidencia. Dependiendo del sistema que uses para hacer tracking de incidencias es posible que cambie el formato. Por ejemplo, si usas Redmine cada incidencia que crees tiene asignado un número con el siguiente formato, #12458. Este número lo podemos aprovechar igual en el commit. De esta forma sabemos a qué desarrollo pertenece ese commit.

Tipo.

Siguiendo el ejemplo de categorias del paquete git-journal (El cual recomiendo, aunque no es necesario en este post) tendremos diferentes tipos para marcar nuestros commits:

  • [Added] – Indica que el commit a añadido nuevas funcionalidades, configuración, archivos, etc.
  • [Changed] – Indica que el commit contiene cambios en funcionalidades, configuración, archivos, etc.
  • [Fixed] – Indica que se ha fijado un bug.
  • [Improved] – Indica que el commit contiene mejoras en el código, normalmente relacionadas con rendimiento.
  • [Removed] – Indica que se han eliminado funcionalidades, configuración, archivos, etc.

Como puedes ver, con 5 simples palabras definimos qué contiene nuestro commit.

Titulo.

Aquí hay cierto dilema general. Hay quien piensa que el título del commit tiene que describir los cambios que se han realizado otro piensan que debe de ser algo corto y, usando el campo de descripción del commit, profundizar en detalles. Yo soy de los segundos 👓.

La cosa es la siguiente, con toda la información que tenemos hasta ahora con el emoji, el scope y el tipo. No hace falta que tengamos un titulo excesivamente grande, tiene que ser sencillo y directo. Luego ya en la descripción comentas qué has añadido, arreglado, mejorado, eliminado, etc. Con más detalles y verborrea.

En resumen.

Con esta sencilla estructura obtenemos muchísima información contenida en un sencillo commit.

Esta estructura no me la he inventado yo, es la estructura que utiliza el programa de terminal gitmoji. Este software te permite estandarizar los emojis para usarlos a nuestro favor. Échale un ojo.

Cómo obtener.

Hay varios puntos para obtener todo lo que te he comentado hasta ahora.

Disciplina.

Primeramente con disciplina, hay que conseguir que todos los trabajadores que estén involucrados en el proyecto y usen git utilicen esta plantilla. De esta forma, y con el tiempo, conseguiremos una valiosa información que os describiré más adelante.

Segmentación.

Imprescindible para los datos que queremos obtener.  Si en tu empresa están enamorados de los rebase que sepas que es contraproducente. Se pierde mucha información valiosa en pos de tener un par menos de commits en la rama master.

Más infor sobre git rebase.

Sí que es cierto que ayuda a que la rama esté más limpia, pero en casi 2 años que llevo trabajando como desarrollador no he visto ni una vez que haya problemas con tener muchos commits en master, al fin y al cabo, todo acaba ahí.

Es por esto que te invito a que segmentes los commits, por ejemplo, si estás haciendo un desarrollo para una nueva funcionalidad y te encuentras con un bug. Separa el desarrollo en dos commits; uno que contenga el desarrollo y otro con el arreglo del bug. De esta forma queda más ordenado y separado.

Esto trae consigo algunas ventajas:

  • Cada cosa en su sitio. A la hora de hacer review de los cambios, puedes ver los de la nueva funcionalidad por un lado y el arreglo del bug por el otro. Aunque no lo parezca a primera vista, esto reduce considerablemente el tiempo de revisión. Te centras en secciones más pequeñas de código sin tener distracciones o código de otras cosas que no vienen a cuento.
  • Mejor visualización. Tanto si usas git log como si miras los commits en programas como Github, Gitlab, Gitkraken, <programa de git chachi-pistachi>. Más separado y ordenado es igual a mayor agilidad.
  • Facilidad de volver atrás. Siguiendo con el caso de “uno que contenga el desarrollo y otro con el arreglo del bug”, si se da el caso de que tienes que echar atrás los cambios del bug (porque has provocado otro, pam pam) entonces basta con tirar atrás ese commit y listos. No estás afectando al desarrollo de la nueva funcionalidad, ¿A que es genial? 🤭.

Análisis.

Una vez tengamos todo lo anterior mencionado, tendremos que analizar los commits que se han dado durante pongamos 1 mes. Cómo has podido ver hasta ahora, tenemos: qué tipo de commits tenemos (tipo), hacia donde van dirigidos (scope), título y emoji.

Pero realmente para lo que es un análisis, solo nos hace falta el tipo y el scope, siendo el tipo el más necesario. Veamos por qué usando un ejemplo.

Tenemos un proyecto en el que llevamos trabajando 1 mes. Durante ese mes, vemos que el recuento de commits es de 20, no está mal.

Si nos ponemos a analizar cada commit vemos lo siguiente:

  • 4/20 son de tipo [Changed].
  • 7/20 son de tipo [Fixed].
  • 7/20 son de tipo [Added].
  • 2/20 son de tipo [Removed].

Viendo esto, podemos intuir varias cosas. Primero de todo, se han arreglado tantos bugs como añadidas funcionalidades. Luego, se han hecho pequeños cambios y eliminado algunos archivos pongamos.

Esta información de buenas a primeras no parece muy relevante, ¿verdad?. No nos dice nada acerca del equipo, de cómo funciona o de si va bien o mal. Y esto es porque hace falta tiempo. En un mes es raro que tengas suficiente información como para extraer que tan bien va el equipo o el desarrollo.

Si con el tiempo, vemos que cada mes estamos arreglando una media de 9 bugs y tenemos una media de 8 en commits tipo [Added]. Aquí sí que podemos empezar a ver problemas ya que hay más arreglos de bugs que de desarrollo puro de la aplicación.

Pero incluso podríamos analizar los picos (si hubiese). En un mes, vemos un pico de [Fixed] que va a 14, esto es alarmante de narices. Está bien que se arreglen bugs, pero no está bien que haya tantos. Podría significar varias cosas: falta de formación de nuestros desarrolladores, mala gestión, mala revisión del desarrollo o sencillamente falta de motivación.

Sea como fuere, estos datos nos sirven a modo de alarma. Son capaces de decirnos “Hey, que tienes una media de [Fixed] muy alta, algo pasa”, “Hey, que de repente tienes muchos [Removed], cuidado con eso”, “Hey, que veo un pico de 20 en commits tipo [Improved], algo no se hizo como tocaba desde un principio.”.

Conclusión.

Git  puede ser una herramienta potente, no solo para gestión de proyecto sino también para ver cómo va el equipo, el desarrollo, la gestión e incluso a veces, la moral.


Enhorabuena, has ganado el logro de lector 📖 al llegar hasta aquí. A no ser que hayas hecho scroll sin más, entonces nada de logro.

Si tienes algún punto a comentar porque no te queda claro o crees que es incorrecto, déjamelo saber en Twitter.

Sin más, que tengas un hermoso día.