Centralized workflow

Centralized workflow

El repositorio se aloja en el servidor

• Es un clon de el workflow utilizado en SVN/CVS

• Una única rama en el servidor central

• La historia es lineal

Master

Repositorio central (Trunk)

Master

Repositorio central (Trunk)

Master

Repositorio local (clone)

Master

Repositorio central (Trunk)

Master

Repositorio local

Master

Repositorio central (Trunk)

Master

Repositorio local

Master

Repositorio central (Trunk)

Master

Repositorio local

Repositorio central (Trunk)

Master

Repositorio local

Master

Feature branch

Feature branch

Por cada funcionalidad(feature) creamos una nueva rama

• Aislamiento/separación del código de desarrollo

• Compartir código con miembros del equipo 

• Discutir sobre la implementación (PR)

git checkout -b rama-guillermo master

Guillermo comienza una funcionalidad

Master

rama-guillermo

git status
git add <archivo>
git commit

Guillermo escribe algo de código

rama-guillermo

Master

git push -u origin rama-guillermo

Guillermo acaba su jornada laboral y decide respaldar su código en el servidor

rama-guillermo

Master

git push 

Cuando Guillermo acaba de trabajar en su rama (y todos los tests unitarios pasan) entonces decide hacer un pull request

rama-guillermo

Master

Cuando Guillermo acaba de trabajar en su rama (y todos los tests unitarios pasan) entonces decide hacer un pull request

Cuando Guillermo acaba de trabajar en su rama (y todos los tests unitarios pasan) entonces decide hacer un pull request

Después de resolver las diferencias y aprobar la PR, se decide aceptarlo

Master

Como alternativas, si la rama no ha sido compartida o nadie la ha tocado (cuidadin!) se puede hacer un rebase para conseguir una historia lineal

Master

Para los más pulcros, el rebase se puede hacer de forma interactive y comprimir todos los commits en uno (squash)

Problemas

• Para alguno equipos o empresas es demasiado flexible (No permite la existencia de roles)

• Alineamiento con la infraestructura/entornos

• Mantenimiento y separación de procesos

Git Flow

Git Flow

Extiende el modelo 'Feature branch' enfoncándose en la gestión del despliegue (releases)

• Gestión de grandes proyectos con una estrictra metódologia

• Introduce las ramas de desarrollo y despligue

• Permite controlar mejor los cambios

• Alineamiento con infraestructura/entornos

Comenzamos con dos ramas, la rama de producción (rama histórica de despliegue) y la rama de desarrollo (rama de integración)

Develop

Master

tag #2

tag #1

Cada nueva funcionalidad se desarrolla en un rama aparte siempre tomando de base desarrollo (develop)

Feature #3

develop

Cuando llega el momento de un release (fecha/roadmap) se crea un rama nueva para gestionarlo partiendo de desarrollo (develop)

Release #3

develop

Cuando el release se da por acabado se hace merge con master y se etiqueta ese commit con la versión

Release #3

master

tag #3

tag #1

tag #2

También se hace un otro merge con desarrollo (develop) para actualizar posibles cambios (bugs/docs)

develop

Release #3

Además de estas ramas existe la rama 'hotfix', también temporal pero con el objetivo de arreglar un error (bug) en producción (master)

Hotfix #1

master

tag #3

tag #1

tag #2

Se crea a partir de master, una vez terminado  se hace un merge de vuelta a master y develop.

Hotfix #1

master

tag #3

tag #1

tag #2

tag #3.1

Forking Flow

Forking Flow

Difiere en que cada desarrollador tiene su propio repositorio en el servidor

• Las contribuciones integradas sin la necesidad de tener que tener todo el mundo acceso al mismo repositorio

• Facilita el control de permisos/cambios

• Ideal en grandes proyectos generalmente open source

Todo comienza haciendo un fork del repositorio origen

git clone https://github.com/pipo02mix/reveal.git

Luego hacemos un clone de nuestro repositorio y trabajamos sobre el 

Master

Trabajamos con el repositorio como queramos, aunque suele ser buena práctica hacer todos los cambios en un solo commit.

Forked/Master

Master

Para notificar la mejora al propiertario del repositorio original se hace un pull request

Generalmente se inicia una discusión, donde se habla del propio código, estándares de código, tests,...

Una vez solventado los posibles problemas, el propietario suele hacer un merge del código