Metodologías GIT – Centralized Workflow

Metodologías GIT – Centralized Workflow

[:es]Este es el primero de una serie de artículos que haré sobre las distintas metodologías que al momento de redactar estas líneas son ampliamente conocidas y discutidas en el mundo T.I para el trabajo con el también conocido control de versiones GIT.

Si bien ni este documento ni los siguientes pretenden ser un tutorial de GIT, de igual forma se abarcarán algunos tópicos y comandos básicos (o avanzados dependiendo de lo que se requiera mostrar)  como complemento de la metodología tratada.

 

Centralized Workflow

Se trata del workflow o estrategia de trabajo más simple que veremos en esta serie. Desde mi punto de vista, es el paso lógico de adaptación/transición si es que vienes de un sistema de control de versiones como SVN y pretendes comenzar a utilizar GIT.

Esta metodología consiste en mantener un único repositorio y una única rama sobre la cual los desarrolladores van subiendo sus cambios.

Pese a ser tan simple y tener ciertas similitudes, esta metodología aún nos permite visualizar algunas ventajas sobre SVN, por ejemplo, cada desarrollador puede trabajar y hacer commits en su copia local sin afectar el trabajo de los demás hasta el momento de hacer push sobre el branch remoto.

 

Workflow-centralized-image

 

Operación

Tal como mencioné anteriormente, esta metodología trabaja con un único branch Master, similar al trunk si hacemos la analogía con SVN. La primera gran diferencia, es que cada desarrollador puede generar cuantos commits estime necesarios en su rama local hasta llegar a una funcionalidad completa, para sólo entonces hacer un “push” al repositorio. Todo esto sin afectar el trabajo de los demás, ya que todos los cambios pequeños se hicieron localmente.

En general, los pasos para trabajar con esta metodología (o workflow) son los siguientes:

  1. Cada desarrollador realiza un clone de la única rama del proyecto, en este caso Master,  en su working copy para trabajar de forma local.
  2. Un desarrollador crea, modifica o elimina código con la finalidad de completar una historia de usuario, suponiendo que estamos trabajando con Scrum. Para esto puede generar tantos commits en su branch local como estime conveniente, como ya se dijo, sin afectar el trabajo de los demás miembros del equipo.
  3. Una vez que el desarrollador tiene código listo para liberar, hace un último commit sobre su rama local y posteriormente realiza el push a la rama Master remota, quedando de esta forma el código sincronizado y listo para que los demás miembros del team puedan actualizar su código fuente también.

 

Ejemplo

Con el fin de aterrizar un poco más esta estrategia de trabajo, veremos un ejemplo con un proyecto Libros  en el que está trabajando un equipo de tres desarrolladores: Marcelo, Javier y Jimmy.

Para tales efectos, tenemos entonces un repositorio único cuya rama principal Master será la que cada miembro del equipo debe clonar para tener una copia en su equipo.

[code]

$ git clone https://gitlab.com/company/mi-proyecto-prueba

[/code]

Una vez que tenemos el código en nuestro equipo local, cada desarrollador del equipo comienza a trabajar.

Jimmy será el primer miembro del equipo que haga un push sobre el repositorio remoto. No encontrará mayores problemas ya que dicho repositorio se encontrará exactamente igual al momento de hacer el clone. Por esto, será un push absolutamente limpio.

[code]

$git commit -m "últimas modificaciones antes de hacer push"

$git push master origin

[/code]

Cuando el segundo miembro del equipo, que esta vez será Marcelo, llegue a la fase de hacer push de SU código al repositorio, podría encontrarse con el primer problema. Jimmy en su trabajo de implementación de la funcionalidad “búsqueda de libros” ha debido agregar métodos a la clase Libro.

Marcelo por su parte ha debido crear también métodos y atributos que permiten hacer una reserva, para lo cual realizó cambios también en la clase Libro.

[code]

$git commit -m "Reserva de libros finalizada"

$git push origin master

[/code]

Si tanto Jimmy como Marcelo tuvieron la fortuna de no modificar el mismo código dentro de la clase Libro, el push de Marcelo se llevará a cabo sin mayores problemas. Pero si la suerte no nos acompaña, y esto comenzará a suceder en la medida que los proyectos vayan avanzando y aumentando su complejidad  y el número de miembros del equipo vaya en aumento, Marcelo deberá realizar el proceso de merge del código de ambos desarrolladores para poder llevar a cabo, finalmente, el push del código ya sincronizado a la rama Master.

Ahora es el turno de Javier. Debe actualizar el código que recién acaba de terminar y, deberá hacer el mismo proceso que Marcelo para poder dejar el código del proyecto totalmente sincronizado para todos los miembros de equipo.

Resolución de conflictos

En esta metodología el problema más común que se encontrarán es la constante desactualización de código en las ramas locales, más aún cuando los equipos que modifican código de forma transversal en el proyecto. Esto debido a que la única rama remota está sufriendo constantes updates con cada push que se haga sobre ella.

Será necesario entonces contar con una buena herramienta de resolución de conflictos, como el p4merge u otra que sea de su agrado.

[code]

$git commit -m "Reserva de libros finalizada"

$git push origin master
[/code]

CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree.
Automatic merge failed; fix conflicts and then commit the result.

[code]
$git merge tool

[/code]

Para resolver el conflicto, hacer el commit y hacer nuevamente el push del código al repositorio remoto.

 

Ventajas

Esta metodología es especialmente útil para equipos que están cambiando de un sistema de control de versiones como SVN a Git, ya que su línea de trabajo es muy similar. No obstante las diferencias que ya se han mencionado, la utilización de esta metodología permite comprender en la marcha de un proyecto, la filosofía de Git y los comandos utilizados para la operación diaria.

 

Desventajas

La principal desventaja de esta metodología es que, como se está trabajando con un branch local que hace tracking del branch remoto, cada uno de los commits locales que un desarrollador hace pasan a formar parte también del branch remoto, dejando una rama principal (y única) muy sucia y muy compleja de analizar su historia.

 

Recomendación Experta

Como ya he mencionado en más de una oportunidad en este artículo, esta metodología me parece un excelente primer paso para migrarse a GIT ya que se está orientada a comprender el uso básico de este control de versiones. Creo importante que el proyecto que se utilice como proceso de adaptación no corresponda a un desarrollo pequeño, sino más bien un proyecto de envergadura media, de esta forma el equipo se verá enfrentado a problemas de baja dificultad como resolución de conflictos, creación de stashes, utilización de Tags, etc, que le permitan en un siguiente proyecto abordar otras metodologías con características más avanzadas de GIT.

Como último consejo, sería conveniente sobre todo al principio del proyecto, que cada desarrollador tome líneas lo más independientes posibles dentro del desarrollo, para de estar forma comprender primero los comandos a utilizar y luego, comenzar a trabajar con situaciones más complejas como los merges y rebases.

 [:]