Haz rebase para refrescar tu rama

Formo parte de varios equipos de software y, muy a menudo, subimos código a nuestra rama principal. Es habitual en mis equipos no tener una rama develop ni ciclos de lanzamiento. En su lugar, lanzamos con regularidad.

Esto no es lo normal en una gran corporación, pero en empresas ágiles centradas en el software es bastante corriente.

La pregunta es cómo hacerlo sin pisarnos unos a otros.

Git

Todo se reduce a git y a lo ágil. La herramienta con la que gestionamos el control de versiones y un pedacito de la mentalidad de nuestro ciclo de gestión de proyectos.

Git es, sencillamente, una forma de detectar diferencias entre copias. Si la copia de producción contiene A, Joe trabaja en B y Sally en C, Git puede calcular las diferencias y fusionar las copias sin conflictos.

Lo difícil llega cuando el trabajo dura mucho y las contribuciones se suben a intervalos distintos.

Ahí entra rebase. git rebase origin/main es una forma de asegurar que mi trabajo, el que sale de main, está al día con todo lo que han aportado mis compañeros. Es lo correcto y reduce el trabajo repetido cuando más adelante aparecen conflictos. Garantiza que mi trabajo está al día antes de fusionarlo en la rama main. La fuente de la verdad.

Flujo

Una estrategia habitual en los equipos es git-flow. Atlassian lo tiene muy bien definido y no necesita más explicación.

Pero no creo que sea perfecto.

En ingeniería de software, a veces tendemos a automatizar los procesos que apreciamos para ser más productivos. Funcionan bien, pero traen sus propias carencias.

Por ejemplo, una rama de función puede ser un buen mecanismo para probar una función concreta, de modo que cada commit dispare un cuasi-despliegue para mostrar el potencial de la funcionalidad nueva.

El resultado imperfecto es que la rama de función dispara un proceso automático para desplegar esa función de demostración.

Eso es caro y se queda corto.

Ramas de trabajo

Un enfoque sencillo que estoy adoptando en mi equipo son las ramas work/*. Son un concepto parecido a las ramas de función, pero con un espacio de nombres propio para evitar los procesos automáticos.

Las ramas de trabajo llevan el prefijo work/ y se excluyen de forma explícita de las pipelines automáticas. Están pensadas para ser el “autoguardado” del mundo del control de versiones.

Animo activamente a mis equipos a trabajar sobre todo en su rama work/* y a fusionar las funciones en su rama feature/* solo cuando quieren que se ejecute una pipeline.

Para concluir

Aviso de que solo llevo poco tiempo practicando esto con mis equipos y, a pesar del esfuerzo extra de distinguir entre ramas feature/* y work/*, parece que funciona bien.

Reconozco que los pasos de bloqueo también son un buen mecanismo para reducir despliegues y compilaciones innecesarios. Son buenas formas de conseguir algo parecido, pero por desgracia no están disponibles en los entornos en los que trabajo.

Siempre tengo ganas de recibir comentarios y quizá sugerencias de nuevas formas de trabajar. Si tienes alguna idea, escríbeme.