Ramificación de Git para equipos ágiles

El paso a Git ofrece un nivel totalmente nuevo de metodología ágil para equipos de software. A continuación, detallamos por qué.

Sarah Goff-Dupont Sarah Goff-Dupont

Liberados de las engorrosas congelaciones de código y de las grandes fusiones ("merge") monolíticas que inundan el control de versiones centralizado, los desarrolladores pueden aislar el trabajo en curso y crear estrechos fragmentos verticales fácilmente. Las ramificaciones y fusiones son tan sencillas con Git que muchos equipos crean nuevas ramas para cada historia de usuario o corrección de error que implementan. Este modelo se están convirtiendo rápidamente en la nueva regla de oro de los equipos ágiles y por una buena razón.

Prepárate unas palomitas y disfruta de uno de nuestros seminarios más populares. En él, aprenderás lo siguiente: 

  • Cómo un modelo de rama por tique ayuda a los equipos a ofrecer código de trabajo en un flujo continuo
  • Cómo ven los desarrolladores el workflow
  • Cómo se integra con tus prácticas de revisión del código e integración continua existentes
  • Qué compensaciones hay que tener en cuenta a la hora de evaluar este modelo

Mira y aprende

Preguntas y respuestas

Pinta bien ¿verdad? 

Ahora, si eres como yo, difícilmente aguantarás sentado mientras transcurre la sección de preguntas y respuestas del seminario web. No pasa nada, puedes admitirlo. Por ese motivo, he transcrito una serie de preguntas útiles para que puedas analizarlas y leerlas cuando más te convenga. 

P: ¿Cómo se pueden gestionar los números de versiones de todas estas ramas? ¿Cómo se diferencian esas líneas de código? 

R: Los equipos suelen poner a la rama el nombre de la versión de lanzamiento correspondiente. Por ejemplo, cuando el equipo que crea Stash ha terminado de preparar su versión 2.9, crea una rama estable llamada "stash-2.9", de modo que cuando la ven en los informes, queda claro de qué rama se trata. Puedes utilizar la convención de nomenclatura que mejor funcione para tu equipo; tan solo tienes que incluir en número de versión en alguna parte.

P: En tus ejemplos, has tenido a una persona trabajando en cada rama. ¿Cuál es la estructura y la convención de nomenclatura de ramas adecuada para cuando dos personas trabajan en una misma historia?

R: Puedes tener a dos personas trabajando en la misma rama de tiques. Tan solo tienes que asegurarte de seguir un protocolo de ramas compartidas básico como no rebasar y, en general, evitar hacer las cosas en una copia local de la rama, dado que hacerlo podría ocasionar fuertes dolores de cabeza a la otra persona implicada. Otra opción es que cada colaborador cree su propia rama para ese tique y, después, hacer un merge con ellas de forma frecuente. La convención de nomenclatura para ello podría ser <nombre/iniciales>-<clave de tique>-<descripción> (por ejemplo, sara-DEV-1234-nombre-empresa-mal-escrito-en-página-principal), que es más o menos lo mismo que utilizamos para ramas de un único desarrollador.

P: ¿Cómo se gestionan las dependencias si no se fusiona cada cambio en una sola rama en cuanto este se aplica en una rama de versión?

R: Si las partes dependientes son los dos trabajos en curso, entonces los desarrolladores que trabajan en cada parte del código deberán hacer un merge con sus cambios de forma frecuente. Puedes hacerlo en Git sin tener que hacer un merge primero de cada rama en una rama centralizada; bastará con que el otro desarrollador y tú fusionéis las ramas directamente. La otra opción consiste en usar la rama de integración compartida de la que hablamos antes.

P: Hace algún tiempo, Martin Fowler rebatió la creación de ramas de funcionalidades diciendo que obstaculiza la refactorización y que, mientras que la rama de funcionalidades cobra vida, tú realizas un desarrollo continuo, pero no una integración continua.

R: Sí, conozco su artículo sobre ese tema. Lo publicó hace ya unos años; en 2008 o 2009 quizás. Creo que nuestras oportunidades para ejecutar la integración continua (IC) en ramas de funcionalidades han avanzado bastante desde entonces. Y, como dije en la sección de consideraciones de este seminario web, un enfoque de rama por tique significa que no estás ejecutando una IC "pura". Estás realizando un desarrollo continuo y unas pruebas continuas, pero no una integración continua. Sin embargo, puedes acercarte más a una IC pura, incluyendo una rama de integración compartida en tu esquema de ramificación.