Gestiona el código fuente de tu equipo con ramas de desarrollo

El branching permite el desarrollo en paralelo sin interferencia entre las diferentes ramas

Visitas: 425

Una de las discusiones más habituales en los equipos de desarrollo (aparte del editor o IDE a usar), es la forma de utilizar el software de gestión de código, y más concretamente, a como se deben organizar las diferentes ramas en un proyecto.

Una definición muy simplificada sobre lo que es una rama en un software de gestión de código es que es un duplicado del código de la rama principal, en un determinado momento en la línea temporal de desarrollo. Es decir, en un determinado momento en el tiempo, se saca un duplicado de la rama principal y esto permite trabajar en paralelo en ese rama sin afectar a la rama principal. El objetivo de trabajar en paralelo es no afectar al resto del equipo mientras dure el desarrollo de esa característica e integrarla una vez esté terminada.

El principal punto de discusión está en lo que dice la teoría, y lo que al final hay que hacer en la práctica.

Teoría

En teoría, cada equipo (en algunos casos, incluso cada miembro del equipo) debe crearse una rama sobre la que trabajar, ir integrando los cambios que hacen otros en la rama principal, y, una vez finalizado el trabajo, mezclar esta rama con la rama principal.

Práctica

La teoría suena perfecta, de hecho, yo era partidario no hace mucho de la versión teórica, pero la práctica me ha llevado a cambiar de opinión. El principal motivo es que la teoría choca con el componente humano. El componente humano, en este caso concreto, se manifiesta de dos formas bastante frecuentes: pereza y error.

Pereza

Trabajar conforme dicta la teoría, obliga a integrar los cambios de la rama principal en nuestra rama de forma frecuente, para mantener nuestro código lo más actualizado posible, y que, cuando haya que integrar nuestra rama en la rama principal, cueste lo menos posible.
En la práctica, esto no se hace al ritmo que se debería. El día a día hace que no haya tiempo material para hacer esas integraciones, ya que no son obligatorias para poder seguir trabajando. Es decir, la persona que trabajan en la rama, pueden seguir escribiendo código sin estar obligados a hacer esas integraciones, con lo cual, por pereza, no se hacen, y se dejan para el final.

Error

Dicha pereza lleva a realizar integraciones más grandes, lo que al final, conlleva al error. Cuando no se puede realizar la integración de forma automática y hay que resolver los conflictos, esto se debe hacer manualmente, lo que induce al error, bien por desconocimiento, bien por falta de atención.

Resultados

Los resultados que se obtienen de aplicar la versión teórica, es que al final, los tiempos de integración son desconocidos, no se sabe a priori cuanto se va a tardar en realizar una integración, y esos tiempos se van acumulando en el proyecto causando retrasos.

Solución

Trabajar en la rama principal. Siempre que le digo esto a un programador que ha trabajado utilizando ramas, se lleva las manos a la cabeza y comienza una discusión sobre "lo que todo el mundo hace", o lo que "se lleva ahora", lo cual, lo único que consiguen es que nos enfrasquemos en una discusión en la que tengo que explicar todos estos puntos uno por uno. La experiencia nos tiene que servir para aprender de nuestros errores, no cometerlos en un futuro y no nos tiene que dar vergüenza reconocer que estábamos equivocados. Y otro problema puede venir al intentar hacer las cosas tal y como las hace todo el mundo, sin cuestionar si es la forma más adecuada.

Posibles usos válidos de ramas

Experimentos

Si queremos hacer un experimento con el código para probar algo que anticipamos que puede romper muchas cosas, es mejor hacerlo en una rama, ya que a priori, no es código que se vaya a integrar en el producto, a no ser que el experimento salga bien.

Optimizaciones

Las optimizaciones del código suelen tener varios componentes desconocidos:

  • El tiempo que va a llevar su realización
  • Los posibles beneficios que aportan
  • Dependiendo del resultado, se integrará o no, aparte que puede afectar a bastante código, por lo tanto, es aconsejable trabajar en una rama aparte.

Conclusión

No tengamos miedo de hacer las cosas como consideramos que deben hacerse, sin importarnos demasiado lo que esté haciendo todo el mundo, la experiencia que adquirimos en base a nuestros errores tiene que beneficiar a los proyectos que vamos haciendo después, y debemos estar atentos a estos resultados para no repetir los errores del pasado.

Autor

Imagen de José León

Director Área Business Software Solutions

CAPTCHA
Esta pregunta es para comprobar si usted es un visitante humano y prevenir envíos de spam automatizado.