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
Buscar temas

Liberados de las engorrosas congelaciones de código y de las grandes fusiones 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 web más populares. En él, aprenderás lo siguiente: 

  • Cómo un modelo de rama por incidencia ayuda a los equipos a ofrecer código funcional en un flujo continuo
  • Cómo ven los desarrolladores el flujo de trabajo
  • Cómo se integra con tus prácticas de revisión del código e integración continua existentes
  • Qué concesiones 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 publicación correspondiente. Por ejemplo, cuando el equipo que crea Stash estaba terminando de preparar su publicación 2.9, creó una rama estable llamada "stash-2.9", de modo que cuando la veían en su repositorio, quedaba claro de qué rama se trataba. Puedes utilizar la convención de nomenclatura que mejor funcione para tu equipo; tan solo tienes que incluir el número de versión en alguna parte.

P: En vuestros ejemplos, una persona ha trabajado 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 incidencias. Tan solo tienes que asegurarte de seguir un protocolo de ramas compartidas básico como no reorganizar y, en general, evitar hacer las cosas en tu copia local de la rama, dado que hacerlo podría ocasionarle quebraderos de cabeza a la otra persona implicada. Otra opción es que cada colaborador cree su propia rama para esa incidencia y, después, fusionarlas de forma frecuente. La convención de nomenclatura para ello podría ser <nombre/iniciales>-<clave de incidencia>-<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 las 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 desarrollo?

R: Si las partes dependientes son los dos trabajos en curso, entonces los desarrolladores que trabajan en cada parte del código deberán fusionar sus cambios de forma frecuente. Puedes hacerlo en Git sin tener que fusionar primero cada rama con 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 función diciendo que obstaculiza la refactorización y que, mientras que la rama de función está vigente, estás realizando una compilación continua, 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 función han avanzado bastante desde entonces. Y, como dije en la sección de consideraciones de este seminario web, un enfoque de rama por incidencia 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 creación de ramas. 

A continuación
Code reviews