Git Flow
Git Branching Model
Git Branches
¿Cómo almacena Git sus datos?
- Git crea snapshots
- Cuando se hace un commit, Git almacena un commit object que contiene:
- Apuntador al snapshot del contenido staged
- El autor del commit
- El metadato mensaje
- Cero o más apuntadores al objeto (u objetos) commit padre de donde viene el presente commit
- El primer commit no tiene padre.
Git Branches
Directorio con 3 archivos:
$ git add README test.txt gretting.txt $ git commit -m 'initial commit of my project'
git commit hace un checksum de todos los directorios del proyecto y los almacena como objetos tree en el repositorio Git.
Con esto, Git crea un objeto commit que tiene los metadatos y un apuntador al objeto tree raiz del proyecto, de tal forma que este pueda recrear este snapshot cuando sea necesario.
Commit Object
Datos de repositorio de un commit simple
Siguientes commits...
Datos de objeto Git para múltiples commits
¿Qué es un Git Branch?
Es un ligero apuntador movible hacia uno de estos commits.
El branch por defecto se llama master. Tras los commits, se le indica al branch master que apunte al último commit hecho. Con cada commit, este apuntador (branch master) se mueve automáticamente.
Branch pointing a través de la historia de commits
Creando un nuevo branch
$ git branch testing
Esto crea un nuevo apuntador hacia el mismo commit donde estás (seguimos en master)
Multiples branches apuntando a un commit
HEAD - Un apuntador especial
Es un apuntador al branch local donde se está trabajando
HEAD apunta a master
HEAD pointer
Para moverse a un branch existente, se utiliza el comando:
HEAD apunta a testing
$ git checkout testing
HEAD se mueve para apuntar ahora al branch testing
Commit sobre testing
HEAD se mueve en cada commit
$ vim test.rb
$ git commit -a -m 'made a change'
Regresando a master
HEAD regresa a otro branch en un checkout
$ git checkout master
Un cambio sobre master
La historia de los branches ha cambiado
$ vim test.rb
$ git commit -a -m 'made other changes'
Git flow
Es una propuesta de branching que ha mostrado ser funcional en proyectos de desarrollo.
Bitbucket
https://confluence.atlassian.com/bitbucketserver/using-branches-in-bitbucket-server-776639968.html
Git flow
Existen dos ramas con tiempo de vida infinito:
- Master
- Develop
Develop
Qué poner en master y develop
Se considera origin/master como el branch principal donde está el código fuente que refleja lo que está en producción.
Se considera origin/develop como la rama que refleja un estado con los ultimos cambios de código liberable para el siguiente release. Es el Podría llamarse "branch de integración"
Branches de soporte
- Feature branches
- Release branches
- Hotfix branches
Feature
Sale desde:
develop
Debe hacer merge con:
develop
Convención de nombrado (Bitbucket):
feature/lo-que-sea
nunca master, develop, release-*, or hotfix-*
Release
Sale desde:
develop
Debe hacer merge hacia:
develop y master
Convención de nombrado (Bitbucket):
release/lo-que-sea
Es una preparación para producción. Pueden corregirse aquí defectos clasificados como bugfixes(no explicado aquí) según Bitbucket
Hotfix
Sale desde:
master
Debe hacer merge hacia:
develop y master
Convención de nombrado (Bitbucket):
hotfix/lo-que-sea
Se utiliza para correcciones urgentes en producción sin interrumpir cambios en la rama de desarrollo.
Conclusión
Si bien no hay mucho de wow en el tema de Git Flow, la importancia radica en la utilidad y el orden que le da a los proyectos.
Es más un modelo mental fácil de comprender, y facilita el desarrollo y el intercambio de este entre los miembros del equipo.
Considera el avance en el desarrollo de nuevas carácterísticas y la preparación de liberaciones al ambiente de producción.
Recursos
- https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is
- http://nvie.com/posts/a-successful-git-branching-model/
- https://confluence.atlassian.com/bitbucketserver/using-branches-in-bitbucket-server-776639968.html