Al trabajar con cualquier tipo de proyecto de software tenemos que resolver problemas como el guardar un backup de tu codigo, asi evitamos que una falla en disco eche a perder nuestro trabajo. Pero que sucede si en el proyecto de software que estamos trabajando llegamos a un callejon sin salida y tenemos que probar una solucion nueva ? Entonces, tendriamos que guardar muchos backups para poder volver a una version anterior. Y que sucede si creamos una copia del proyecto para una funcionalidad experimental como hacemos para integrar esas funcionalidades con la version de produccion ( sobre todo si ha seguido trabajando en paralelo en la version de produccion ). Como gestionamos que varias personas trabajen cada uno sobre una funcionalidad diferente y al final de cada una juntarlas para que funcionen adecuadamente ? Y si al momento de trabajar sobre una caracteristica nueva descubrimos algun problema en la version de produccion ? como volvemos a esa version antigua ? Y si usamos un codigo de backup como integramos esos cambios para no perderlos en la nueva funcionalidad ? Debemos volver a escribirlos ?
Para solucionar todos esos problemas ( y algunos mas ) existe GIT. Git es un sistema de control de versiones de codigo. Que nos permite volver a cualquier version del sistema.
Sin embargo, GIT es muy flexible permitiendonos trabajar en la forma que querramos. Tanta flexibilidad no es muy buena para proyectos y equipos grandes o desarrolladores novatos. Incluso para desarrolladores senior, el desorden puede causar problemas en el proyecto.
GIT FLOW es un flujo de trabajo ( recomendaciones a seguir ) para proyectos en GIT que nos permite usar herramientas simples para automatizar y organizar el trabajo usando GIT.
GIT FLOW nos indica que en todo proyecto debe existir una rama master que sera la encargada de contener el codigo de produccion y una rama develop que mantendra el codigo de desarrollo. Asi como algunas ramas auxiliares: feature, para las nuevas caracteristicas o funcionalidades del sistema, release, para preparar los cambios antes de pasarlos a produccion, y hotfix, para corregir rapidamente los bugs que se pudieran encontran en produccion.
Al iniciar un proyecto con GIT FLOW debemos iniciar la configuracion con el comando
git flow init -d
Este comando no realizara ningun cambio en tu codigo o ramas de GIT. Solo servira para configurar incialmente el proyecto.
Al ejecutar el comando, se crearan ( sino existen previamente ) las ramas master y develop. Las cuales seran usadas para contener el codigo del proyecto en produccion y el codigo del proyecto en desarrollo respectivamente.
Luego, cualquier nueva funcionalidad ( historia de usuario, caso de uso, tarea ) que queramos implementar crearemos una rama con el comando
git flow feature start <nombre de la historia>
En ese momento GIT FLOW, creara una copia del codigo de la rama develop y lo pondra en una rama feature/<nombre de la historia> donde se podra realizar los cambios necesarios. Si al final la caracteristica es desechada ( ya sea porque el codigo no funciono como se esperaba, o se prefiero no desarrollar al final esa historia ) podra eliminarse simplemente borrando la rama sin comprometer el resto del codigo
git branch -d <nombre de la historia>
Una vez termina la historia, para integrarla al resto del codigo simplemente debemos cerrar el feature.
git flow feature finish <nombre de la historia>
Al ejecutar este codigo, GIT FLOW hara un merge de la rama feature con el codigo que esta en develop y luego procedera a borrar la rama feature. En este punto si empiezas a trabajar con otra historia, al crear el feature usara el nuevo codigo en develop.
Al final del sprint cuando ya necesitar pasar todo el codigo funcionando a produccion, deberemos crear una rama release. Donde nos aseguraremos que todo este funcionando correctamente y podremos hacer los ultimos ajustes
git flow release start <version codigo>
Aca podremos hacer cambios, guardarlos en git con nuevos commits y cuando ya este todo listo indicarle a GIT FLOW que debe pasarlo ahora si a produccion.
git flow release finish <version codigo>
En este punto GIT FLOW, integra los cambios de la rama release a develop ( para que los nuevos desarrollos tengan esos ajustes ) y a master ( para hacer el pase a produccion ) y luego borra la rama release
Si en cualquier momento se detecta un bug en produccion ( puedes estar trabajando en otro feature o inclusive estar haciendo los ajustes para un release ) puedes crear una rama hotfix para hacer cambios sobre el codigo que esta actualmente en produccion.
git flow hotfix start <version codigo – numero correccion>
Una vez terminados los cambios se cierra la rama hotfix
git flow hotfix finish <version codigo – numero correccion>
Ahi los cambios hechos en el hotfix, se copian a master para actualizar produccion y a develop para tenerlos disponibles para el desarrollo posterior.
PD: GIT FLOW es una herramienta agnostica, lo puedes usar tanto en github, en gitlab, o en tus propios repositorios de GIT.
PD2: si usas tus propios repositorios de GIT y aun no has visto el tema de permisos y seguridad, te recomiendo gitolite.
