Git Workflow
Álvaro José Agámez Licha
Software Developer en PSL
https://github.com/CodeMaxter
@codemaxter
Flujos de trabajo en Git, y cómo no morir en el intento.
¿Qué es Git?
Git es un sistema de control de versiones para el seguimiento de los cambios en los archivos de computadora y la coordinación del trabajo en esos archivos entre varias personas. Se utiliza principalmente para la gestión de código fuente en el desarrollo de software, pero se puede utilizar para mantener un seguimiento de los cambios en cualquier conjunto de archivos. Como sistema de control de revisiones distribuidos, está dirigido a la velocidad, la integridad de los datos y el soporte para flujos de trabajo no lineales distribuidos.
Oye, oye, despacio cerebrito
Es una herramienta para ayudar a mantener las diferentes versiones del código de las aplicaciones que desarrollamos, facilita el trabajo en equipos distribuidos, minimizando el riesgo de perder código fuente.
¿Qué es Git?
¿Por qué usar Git?
Ayuda a organizar y coordinar el trabajo distribuido de un conjunto de personas que de otra manera tendrían que destinar una buena cantidad de tiempo y esfuerzo en salvaguardar el código fuente y no dispararse en el pie a sí mismos y a los otros.
Comandos Básicos
Git nos ofrece un gran conjunto de funcionalidades a modo de comandos (sí, la línea de comandos); entre los que más usaremos están los siguientes:
- git clone
- git init
- git checkout
- git add
- git commit
- git push
- git status
- git merge
- git stash
Git Workflow (¡al fin!)
Esencialmente, no es mas que un conjunto de procedimientos que cada miembro del equipo debe seguir, para llegar a un proceso de desarrollo de software ordenado y bien administrado.
¿Qué es Git Workflow?
En Git es muy fácil crear, mezclar y eliminar ramas, y Git Workflow se sustenta en esta facilidad para poder mantener un flujo de trabajo bien definido y organizado.
¿Todo eso para esto?
Git Branching Model
Descentralizado pero centralizado
Cada desarrollador hace pull y push hacia origin. Pero además de las relaciones push-pull centralizadas, cada desarrollador también puede obtener cambios de otros compañeros para formar equipos secundarios.
Ramas Principales
El trabajo se organiza en dos ramas principales:
- master: todo commit que pongamos en esta rama debe estar preparado para subir a producción.
- develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto.
Ramas Secundarias
Junto a las ramas principales master y develop, Git Workflow utiliza una variedad de ramas de apoyo para facilitar el desarrollo paralelo entre los miembros del equipo, facilitar el seguimiento de funcionalidades, preparar los lanzamientos a producción y ayudar a solucionar rápidamente los problemas críticos en producción.
Los diferentes tipos de ramas que podemos usar son:
- feature: se utilizan para desarrollar nuevas funciones para la próxima versión o una versión futura distante.
- release: se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y corrigen los últimos bugs antes de pasar el código a producción.
- hotfix: se utilizan para corregir errores y bugs en el código en producción, son temporales y no se planifican.
$ git checkout -b myfeature develop
Switched to a new branch "myfeature"$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin developIncorporando una característica terminada en develop.
Creando un feature branch.
El flag --no-ff hace que el merge siempre cree un nuevo objeto de confirmación, incluso si el merge se puede realizar con un fast-forward. Esto evita perder información sobre la historia de una rama feature y agrupa todas los commits que juntos agregaron la característica. Compararemos:
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)Creando un release branch.
Terminando un release branch.
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2El lanzamiento ya está hecho y etiquetado para futuras referencias. Sin embargo, para mantener los cambios realizados en la rama de release, debemos mezclarlos nuevamente a develop.
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).Ahora hemos terminado y la rama de release puede ser eliminada, ya que ya no la necesitamos:
Creando the hotfix branch.
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)Luego, corregimos el error y enviamos la corrección en uno o más commits separados.
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)Terminando la rama hotfix
Primero, actualizamos master y etiquetamos el release.
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1Luego, incluimos la corrección en develop también:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).Finalmente, elimininamos la rama temporal:
Eso es todo amigos...
¿Preguntas?
Referencias
Herramientas
Git Workflow
By Alvaro Agamez
