Flujos de trabajo o buenas prácticas con Git
Empecé a utilizar git bastante tarde, no hace ni tres años. Como mucha gente venía de Subversion (y antes de CVS, ¡mucho antes!). Y como la mayoría el tema de las ramas en Subversion lo usábamos de poco a nada.
Así que el primer paso cuando te encuentras con Git es, además de los conceptos bastante diferentes, es adaptarte con los mínimos cambios a tu manera de trabajar. Es natural, y no es que sea un error, pero cuanto menos pases en esa fase mejor.
El tema es que las ramas, las fusiones de ramas y todas esas operaciones, que en Subversion eran realmente calvarios, en el caso de Git no sólo funcionan bien sino que es la manera de trabajar más recomendada.
Por supuesto yo pasé mi fase de trabajo centralizada y lineal con Git. Enseguida lees artículos y ves ejemplos pero requieres un par de momentos de “iluminación de bombilla” para entener algunos conceptos. Entonces entras en la fase de la encrucijada. Empiezas a entender como funciona git (branch, merge, rebase, checkout…) pero te das cuenta que, como buena herramienta flexible, no te condiciona una manera de trabajar. La duda entonces es por donde ir, qué camino seguir.
Aquí es donde esta página web de tutoriales de Git viene como anillo al dedo. Presenta un resumen de los modelos más habituales de trabajo con explicaciones claras y diagramas muy didácticos. Muy recomendable aunque para entenderlo hay que tener una cierta idea de Git.
Yo ahora mismo me he quedado en la fase del Feature Branch Workflow. Es, de hecho, al que pasé tras unas semanas con Git y empezar a entender como funcionaba. No es que lo descubriera por mi mismo sinó que lo leí en varios sitios, por ejemplo en este artículo. He revisado los otros modelos pero para el tamaño de los proyectos en los que actualmente estoy trabajando (yo soy el único desarrollador y son aplicaciones pequeñas) mi modelo actual me sirve de manera más que suficiente.
Ojo, que la relación de modelos de trabajo tampoco es palabra sagrada. Por ejemplo un proyecto relativamente grande (la propia github.com) utiliza el modelo más sencillo. En este artículo uno de los desarrolladores lo explica muy bien.