A la hora de trabajar con git, existen varios formas de lograr con éxito una buena organización. Existen 2 métodos que proponen una forma de trabajar bajo ciertas normas, ninguna resulta ser perfecta, ninguna cubre todos los casos y es posible que necesitemos nuestra forma de realizar un flujo de trabajo y conocer estos métodos nos brindará una idea como hacerlo.
GitFlow
Gitflow o flujo de git es una manera de trabajar ordenando el repositorio en varias ramas que se corresponden con cada fase del desarrollo de la aplicacion.
La propuesta de este flujo de trabajo cuenta con 5 ramas:
- master
- hot-fix
- release
- develop
- feature
Master
Este modo de trabajo nos propone dejar master donde se encuentren las versiones finales, similar a los tags.
Desde master de desprende hot-fix, para tratar incidentes urgentes generalmente rapidos y cortitos.
Develop
Desde master nace la rama de develop, una especie de borrador de master. Desde aqui cada desarrollador crearia su propia rama de trabajo feature-xxx.
Desde ahi uno es libre de seguir creando tantos branch locales como se necesite. Lo importante es, un vez finalizado el trabajo, mergear a develop.
En este punto, nace release, para corregir los ultimos detalles y adecuar al entorno del cliente. Una vez lograda cerrar las caracteristicas del nuevo desarrollo, se integra en develop y desde esta ultima se devolveria a master. Para finalizar se crea el tag.
GitHubFlow
Githubflow o flujo de github, es una manera de trabajar mas minimalista, con solo una rama principal(master) y la rama de turno para generar cambios.
Las caracteristicas principales son:
Todo en master es deployable(desplegable a nivel productivo), esto es ideal a la hora de trabajar con integracion continua y delivery continuo.
Cada nueva caracteristica requiere hacer un branch desde master, y pusheando al remoto hasta lograr una version de pruebas.
Podria haber tantas ramas como caracteristicas simulteneas se requieran.
Si un compañero finalizo su trabajo e integro en master, al crear la nuestra desde la misma instancia, se puede traer sus cambios y sumarlos a los propios.
Los pasos a seguir en flujo de trabajo son:
- Crea tu propia rama, desde master
- Trabajar de manera local pusheando los commits a la rama remota
- Cuando la rama este lista para el merge con master se abre un pull request.
- Se conversa y revisa el codigo con el grupo de trabajo
- Deploy y testing en produccion, los arreglos y adecuaciones de configuracion se realizan en este punto
- Merge a master, luego tag.