¡Hola hola! Soy Juan Ramón González Morales, programador PHP en Jaén. Aquí estamos con un nuevo post y voy a hablar de la organización de tareas con git.
Hablando un poco de cómo nos organizamos las tareas a realizar, en distintas ramas de tareas, ramas de desarrollo y la rama de producción. Así como también algunos consejos que he ido adquiriendo a partir del uso de git y de ir definiendo una organización de tareas estable y fluida.
¿Qué es git?
Primero de todo, ¿qué es git?
Git es una potente herramienta que sirve para versionar código. Podremos mantener un historial de cambios y movernos entre ellos de manera rápida.
Una cosa importante acerca de git es que es software libre. Esto es una ligera idea, ya que no es el principal tema del post, os voy a dejar enlaces para acceder a más información de git a continuación.
Enlaces con más información de git
https://openwebinars.net/blog/que-es-git-y-para-que-sirve/
https://es.wikipedia.org/wiki/Git
Ramas principales
La manera en que organizamos las tareas en Git, la rama principal main otrora llamada master. En la rama principal está el código que está en producción, es decir, el código que el usuario está viendo o usando en estos momentos.
Otra de las ramas principales, son las ramas épicas, éstas son ramas que van a contener una gran cantidad de tareas. Por ejemplo, para un desarrollo de varios meses o algún proyecto más grande y que implique varios proyectos, se puede englobar en una rama épica.
Un ejemplo de rama épica sería llamada así: epic/taskID-new-app-example
Comenzaría por epic seguido de la tarea, usando el ID para la tarea, y una descripción usando guiones.
Una épica, podría ser por ejemplo, una nueva aplicación. Esta aplicación necesitaría de varías partes, por ejemplo:
Desarrollo de la parte back, con la base de datos, la capa de seguridad, los tests …
Desarrollo de la parte visual o front, con el diseño web, la aplicación Android …
Es decir, tenemos un complejo desarrollo muy unido, pues eso sería un uso correcto de una rama épica.
Ramas de desarrollo
Las ramas de desarrollo también son muy importantes para la buena organización de las tareas en git. Éstas son las llamadas releases. Las ramas de desarrollo o releases incluyen un paquete de tareas que ya está probado para pasar a producción.
Las ramas release las tenemos versionadas y usamos la versión para darles nombre.
Una rama release se llama normalmente así: release/1.0, release/1.2, release/2.3 ….
Es decir, las nombres así, release y le ponemos la versión en la que estamos. Las ramas de desarrollo, salen de la rama principal o main que está en este momento en vivo o en producción.
Una vez que tenemos la rama de desarrollo lista y se han pasado los tests. Se le pasan tanto tests unitarios como funcionales y de integración, se prepara un día para mergear la release con la rama main. Esto es, añadir a la rama principal el paquete de cambios que se ha estado desarrollando.
Un pequeño ejemplo de esto para respaldar lo anterior
En la imagen superior se puede verlo que he estado comentando antes, he querido únicamente sacar una parte del nombre de las tareas.
Tenemos la rama principal, y a ella se van añadiendo las ramas de desarrollo, lo que son las releases, en este caso, están marcadas de amarillo porque también están etiquetadas usando los tags.
Podemos ver que por ejemplo la release 3.56.0 include dos tareas que han sido entregadas, en este caso 3995 y 3985. En principio, esas 2 tareas simples se mergearon (en realidad es rebase) en la release y esta una vez terminadas y probadas en su conjunto pasaron a la rama main de producción.
Ramas de tareas simples
Las ramas de tareas simples, es una rama que únicamente va a tener un pequeño cambio, lo que es una tarea en sí. Pueden ser más o menos grandes, pero si una tarea pensamos que va a durar más de 2 días, tenemos que simplificarla en tareas más simples.
La organización en git de las ramas de tareas simples siempre deben de crearse de la release a la que pertenece, y estar pendientes de estar actualizada con la release a la hora de integrarse. Esto quiere decir, que una vez que vayamos a hacer el pull request a la release, tenemos que actualizar la release con git pull y si se han añadido nuevos cambios, rebesear los cambios de la release en la rama de la tarea.
Las ramas de tareas, las llamamos de la siguiente manera: feature/taskID-add-account-check-to-api-helper
Podemos ver que es muy descriptivo, indicamos que es una nueva tarea o feature, con su id y con una pequeña descripción de lo que se va a hacer en la tarea.
Una buena práctica en las ramas de tareas, para mantener el orden. es una vez que la tarea está hecha si acabamos con 3,4 o 5 commits, unirlos todos esos commit en uno solo para tener una historia de git lo más limpia y clara posible, aunque a veces es bueno tener varios commit si queremos tener algo en concreto, por mi parte siempre he sido de pensar que una tarea debe de tener un único commit.
Bugfix chores y refactors
Así, como los tipos anteriores de ramas, son los que se usan el 95 % del tiempo, también hay otras ramas para otras tareas especiales.
Por ejemplo, las ramas de bugfix, son para hacer arreglos rápidos, que se pueden incluir en una nueva release y que arreglan un fallo que se había escapado y ha salido después de estar en producción.
Se hace una nueva tarea, se añade a la release, se prueba y se manda a producción en un corto espacio de tiempo, por lo general en el mismo día.
Las ramas chores, son ramas cuando se añaden actualizaciones de configuración o algo, por ejemplo en composer o cambios del estilo. Es decir, no influyen en el código.
Las ramas refactor, son ramas donde no se va a cambiar la funcionalidad, pero se va a cambiar el código buscando una mejora del mismo. El 99.99 % de las veces será para un código más limpio y fácil de entender o una optimización de una query.
Resumen
Ya os he hablado de la organización de las tareas y os he explicado un poco los tipos de ramas que creamos.
En resumen, tenemos la rama principal o main donde está el código en producción.
Las ramas de desarrollo, release o epics, y las ramas de tareas que se incluyen dentro de estas ramas de desarrollo antes de pasar a producción. Gracias a la organización de tareas, se ha conseguido tener de un vistazo los cambios realizados a lo largo del tiempo.
Además, también os he hablado de otro tipo de ramas menos comunes pero también útiles. Por supuesto hay más tipos de ramas y distintas maneras de organizar las tareas en git, pero esta que seguimos nos ha hecho trabajar con un flujo cómodo y sencillo a la vez que fácil de enterder por todos los miembros del equipo.
Enlaces y referencias
https://openwebinars.net/blog/que-es-git-y-para-que-sirve/
https://es.wikipedia.org/wiki/Git
https://codigofacilito.com/articulos/buenas-practicas-en-commits-de-git
Comparte 🙂
Si te ha gustado el contenido de este artículo no te olvides de compartirlo ya que con eso me harías muy feliz. GRACIAS 😉
Participa 😉
Además de todo ello, si tienes dudas o puedes aportar algo con un comentario, no dudes en hacerlo. GRACIAS 😉