Flujos de trabajo en git

A pesar que sigo considerando que Bazaar es un mejor sistema de versionamiento (eso es motivo para otro post), poco a poco he ido aprendiendo un poco más de git.

Por supuesto, uno de los puntos más atractivos de git es GitHub, y quizás uno de los menos es la falta de estructura en el flujo de trabajo.

Quizás parezca contradictorio plantear que existe “demasiada libertad” en la forma de trabajar con git en torno a un proyecto, pero es fácil darse cuenta que cuando se trata de coordinar el trabajo de un grupo de personas en torno a un proyecto es necesario tener algunos acuerdos básicos sobre la forma en que se usan las herramientas utilizadas para conseguir sus objetivos.

Si aun no te parece algo necesario, ponte en la situación en que estás utilizando tabs para indentar el código mientras que uno de tus compañeros prefiere hacerlo con espacios… molesta, ¿cierto? Y lo que es peor, probablemente te hace perder tiempo.

Con las herramientas de control de versiones pasa lo mismo, y con git pasa algo aún más crítico: si alguien que está trabajando en el proyecto no tiene la costumbre de incorporar los cambios de sus compañeros en su repositorio, pueden aparecer fusiones innecesarias que ensucian el historial del proyecto (aparecen cambios hechos dos veces por distintas personas) o incluso pueden llevar a revertir algunas modificaciones.

En git existen (al menos) dos flujos que son lo bastante populares como para poder considerarlos convenciones “ampliamente aceptadas”: git-flow y github-flow

git-flow está centrado en el release; es decir, está pensado para aquellos proyectos que tienen entregables y ciclos de desarrollo bien definidos. Piensa por ejemplo en una aplicación para móviles.

git-flowEste flujo está ampliamente documentado en el post A successful Git branching model.

Por otra parte, el flujo GitHub está centrado en un modelo de desarrollo iterativo y de despliegue constante; mucho más similar al trabajo en desarrollo web.

Está basado en cuatro principios:

  • Todo lo que está en la rama master está listo para ser puesto en producción
  • Para trabajar en algo nuevo, debes crear una nueva rama de master con un nombre descriptivo (por ejemplo: integracion-oauth)
  • Al necesitar ayuda o querer integrar el trabajo hacia la rama principal se debe abrir una pull request (solicitud de integración de cambios)
  • Alguien debe revisar y visar los cambios para fusionarlos con la rama master
  • Los cambios integrados se pueden poner en producción

El proceso completo está documentado en GitHub Flow, y de forma más notoria, es la forma de trabajo “sugerida” por las funcionalidades propias de GitHub (de hecho, el flujo completo se puede realizar a través de la interfaz web).

Es importante destacar que ambos tipos de flujo hacen un uso intenso de la facilidad de git para crear nuevas ramas, y en ambos casos se mezcla el trabajo descentralizado y centralizado.

Migrar un proyecto desde SVN a Bazaar

Bazaar (bzr) permite interoperar cómodamente con Subversion (svn) y permite implementar fácilmente flujos de trabajo adecuados al desarrollo de tus proyectos

Hace ya algunos meses estoy utilizando Bazaar como sistema de control de versiones para todos mis proyectos nuevos, con resultados muy satisfactorios: me resulta muchísimo más potente que Subversion (SVN) por su funcionamiento como sistema distribuído, y a la vez más sencillo de usar que git (del que sólo le podría faltar la  velocidad).

Uno de estos proyectos ha sido el rediseño de un sitio bastante grande y complejo que hemos desarrollado en AyerViernes y que hasta ahora se encuentra versionado con svn, pero que queremos trasladar a Bazaar por la buena experiencia que hemos tenido. En este proyecto frecuentemente se realizan cambios al modo de funcionamiento de sus diversas características o se agregan nuevas funcionalidades, por lo que no podíamos trabajar bajo el supuesto de congelar el trabajo en el sitio actual y migrar todo inmediatamente a la nueva versión en desarrollo; en síntesis, debíamos ser capaces de:

  • Seguir implementando cambios en la versión en producción
  • Desarrollar paralelamente la nueva versión, sin interferir con la anterior
  • Poder incorporar los cambios de la versión en producción a la versión en desarrollo

Afortunadamente, Bazaar puede interoperar con Subversion gracias a un plugin llamado (adecuadamente) bzr-svn, disponible en los repositorios de Ubuntu.

La estrategia que utilizamos demuestra la flexibilidad y potencia de Bazaar. Los pasos a seguir serían aproximadamente los siguientes:

Continue reading “Migrar un proyecto desde SVN a Bazaar”