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.
Este 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.
