La estrategia de creación de ramas: un camino hacia el éxito

Prácticamente todos los sistemas de control de versiones de hoy en día admiten las ramas; es decir, líneas de trabajo independientes que parten de una base de código central. Dependiendo de tu sistema de control de versiones, la rama principal puede llamarse línea principal, línea predeterminada o tronco. Los desarrolladores pueden crear sus propias ramas a partir de la línea de código principal y trabajar independientemente pero en paralelo.

Las ramas permiten a los equipos de desarrolladores colaborar fácilmente dentro de una base de código central. Cuando un desarrollador crea una rama, el sistema de control de versiones crea una copia de la base de código en ese momento. Los cambios realizados en esa rama no afectan a otros desarrolladores del equipo. Esto es algo positivo, obviamente, ya que las funciones que están en desarrollo pueden crear inestabilidad, lo cual podría llegar a ser muy disruptivo si todo el trabajo ocurre en la línea de código principal. No obstante, las ramas no tienen por qué estar aisladas: los desarrolladores pueden incorporar cambios de otros desarrolladores para colaborar en funciones y conseguir a la vez que su rama privada no se separe demasiado de la principal.

Los modelos de creación de ramas suelen ser distintos según el equipo y son objeto de debate en las comunidades de software. Un tema importante es la cantidad de trabajo que debe permanecer en una rama antes de volver a fusionarla con la principal.

La creación de ramas de publicación se refiere a la idea de que una publicación esté contenida completamente en una rama. Esto significa que en una fase tardía del ciclo de desarrollo, el gestor de publicaciones creará una rama a partir de la rama principal (por ejemplo, "rama de desarrollo 1.1"). Todos los cambios de la publicación 1.1 deben aplicarse dos veces: una vez a la rama 1.1 y luego a la línea de código principal. Trabajar con dos ramas significa trabajo extra para el equipo y es fácil olvidarse de fusionar en ambas ramas. Las ramas de publicación pueden ser difíciles de controlar y de gestionar, debido a que muchas personas trabajan en la misma rama. Todos hemos sufrido tener que fusionar muchos cambios diferentes en una única rama. Si necesitas crear una rama de publicación, créala lo menos separada posible de la publicación real.

Las ramas de función suelen estar asociadas con marcas de función, conmutadores que activan o desactivan una función dentro del producto. Esto simplifica la implementación de código en la rama principal, el control de la función cuando esta se activa y la implementación inicial del código mucho antes de que la función llegue a los usuarios finales.

En Atlassian, nos centramos en un flujo de trabajo de rama por tarea. Cada organización tiene una forma natural de dividir el trabajo en tareas individuales en un gestor de incidencias, como Jira Software. Así, las incidencias se convierten en el punto de contacto central del equipo para esa tarea. La ramificación de tareas, también conocida como ramificación de incidencias, conecta directamente esas incidencias con el código fuente. Cada incidencia se implementa en su propia rama con la clave de incidencia incluida en el nombre de la rama. Ver qué código implementa cada incidencia es muy sencillo: solo hay que buscar la clave de incidencia en el nombre de la rama. Con tal nivel de transparencia, es más fácil realizar cambios concretos en la rama principal o en cualquier rama de publicación anterior que lleve más tiempo.

Dado que la metodología ágil se centra en las historias de usuario, las ramas de tareas funcionan bien con un desarrollo ágil. Cada historia de usuario (o corrección de error) está incluida en su propia rama, de modo que es sencillo comprobar las incidencias en curso y las que están listas para publicarse.

Todos hemos padecido la dificultad de integrar varias ramas en una única solución racional. Generalmente, en los sistemas de control de versiones centralizados, como Subversion, el merge es una operación bastante complicada. Sin embargo, los nuevos sistemas de control de versiones, como Git y Mercurial, tienen un enfoque diferente para realizar el seguimiento de versiones de archivos en distintas ramas.

Las ramas suelen durar poco, lo que hace que sean más fáciles de fusionar y más flexibles en toda la base de código. Entre la posibilidad de fusionar ramas frecuentemente y de forma automática como parte de la integración continua y el hecho de que las ramas de vida corta contienen menos cambios, el "infierno de las fusiones" ya forma parte del pasado en los equipos que usan Git y Mercurial.

¡Por eso las ramas de tareas son tan increíbles!

Un sistema de control de versiones tiene muchas más limitaciones para afectar el resultado de una fusión. Las pruebas automatizadas y la integración continua también son fundamentales. La mayoría de los servidores de integración continua ponen las nuevas ramas a prueba de manera automática, lo que reduce enormemente el número de "sorpresas" en la fusión final en el repositorio remoto y contribuye a la estabilidad de la línea de código principal.