Laboratorio de Git

Modelo de ramas y worflow para empezar a usar git y no morir en el intento

Si eres nuevo en git habrás oido hablar de sus bondades a la hora de trabajar con ramas, te habrán contado su facilidad para hacer merges automáticos, habrás visto que practicamente todos los proyectos open source están en github y seguro que te habrán sugerido empezar a trabajar con git en lugar de cvs o svn.

Soy nuevo en git

Comenzar a utilizar git en un equipo de trabajo que nunca antes lo había utilizado, tiene una gran barrera de entrada:

  • aprender el funcionamiento y los comandos básicos. Con cvs tenemos commit, update, branch, merge,… y todos estos comandos van contra el servidor central. En git tenemos muchas más comandos: clone, commit, push, pull, fetch, merge, rebase, reset, checkout,… algunos trabajan en local y otros en remoto, contra uno o varios repositorios.
  • workflow. El modo de trabajo con cvs es sencillo: actualizas o descargas en local lo que haya en el HEAD o BRANCH en el que tengas que trabajar y vas haciendo commits de los fuentes que se envian al respositorio central. Si hay conflictos en algún fichero al hacer un update o un commit, cvs bloquea antes de subir, resuelves el conflicto y lo vuelves a intentar. En git, aunque básicamente tienes que hacer lo mismo (actulizar tu copia local y subir tus cambios al repositorio/os), la forma de trabajo suele ser distinta: igualmente actualizas tu copia local con los cambios que haya en el repositorio, pero por norma general creas una nueva rama a partir de la principal. Los commits los haces en local y finalmente subes los cambios al respositorio, pero como estás en una rama tienes que hacer un merge con la principal. El modo en el que organices y pactes con el equipo de desarrollo esta “gestión” de ramas y el workflow a seguir, puede marcar la diferencia entre la excesiva sencillez y la extrema burocracia, por lo que hay que buscar el equilibrio para que todos nos sintamos confortables.

El modelo ideal

El modelo ideal no existe, depende de las características del proyecto y de la experiencia del equipo de desarrollo. Hay un excelente artículo describiendo gitlab workflow, con el que, aunque está orientado a trabajar con gitlab, puedes salir con las ideas claras.

La idea es tener la rama master como rama principal, o línea base y crear una rama por cada feature que desees añadir al desarrollo. La rama master es la que estará asociada a tu posible sitema de Integración Continua y estará protegida para que no se pueda hacer un push directo a esta rama. Cada vez que termines una feature se deberá hacer un merge request para integrarla con la rama master y esta solicitud de merge request servirá como punto de unión, para hacer un review con el resto del equipo, como documentación de la resolución de cada feature, etc.

Environment branches

Puede que necesites tener ramas para saber lo que tienes en el entorno de pre-producción y producción. Para ello el modelo gitlab-flow recomienda crear una rama para cada entorno y realizar un merge request desde la rama master a pre o pro cuando se necesite.

Release branches

Si tienes que mantener varias release de tu proyecto, puedes echar un ojo al apartado correpondiente en gitlab-flow.

Trabajar con los Issues de gitlab

Otra buena práctica recomendad por el modelo gitlab-flow es trabajar con el sistema de issues que proporciona la herramienta. La idea es crear un Issues por cada feature, hotfix, etc. con el que trabajes y linkar el issue ID en cada commit o merge request que ralices relacionado con ese issue. De esta manera se pueden trazar los cambios realizados en el software con los requisitos y correcciones realizados.

Otros

Written on February 26, 2015