distributed-workflows.asc

Flujos de trabajo distribuidos

A diferencia de los Sistemas Centralizados de Control de Versiones (CVCSs, Centralized Version Control Systems), la naturaleza distribuida de Git te permite mucha más flexibilidad en la manera de colaborar en proyectos. En los sistemas centralizados, cada desarrollador es un nodo de trabajo más o menos en igualdad con un repositorio central. En Git, sin embargo, cada desarrollador es potencialmente un nodo o un repositorio - es decir, cada desarrollador puede contribuir a otros repositorios y mantener un repositorio público en el cual otros pueden basar su trabajo y al cual pueden contribuir.

Esto abre un enorme rango de posibles flujos de trabajo para tu proyecto y/o tu equipo, así que revisaremos algunos de los paradigmas que toman ventajas de esta flexibilidad Repasaremos las fortalezas y posibles debilidades de cada diseño; podrás elegir uno solo o podrás mezclarlos para escoger características concretas de cada uno.

Flujos de trabajo centralizado

En sistemas centralizados, habitualmente solo hay un modelo de colaboración - el flujo de trabajo centralizado. Un repositorio o punto central que acepta código y todos sincronizan su trabajo con él. Unos cuantos desarrolladores son nodos de trabajo - consumidores de dicho repositorio - y sincronizan con ese punto.

Figure 1. Centralized workflow.

Esto significa que si dos desarrolladores clonan desde el punto central, y ambos hacen cambios, solo el primer desarrollador en subir sus cambios lo podrá hacer sin problemas. El segundo desarrollador debe fusionar el trabajo del primero antes de subir sus cambios, para no sobrescribir los cambios del primero. Este concepto es válido tanto en Git como en Subversion.

Si ya está cómodo con un flujo de trabajo centralizado en su empresa o en su equipo, puede seguir utilizando fácilmente ese flujo de trabajo con Git. Simplemente configure un único repositorio, y dé a cada uno en su equipo acceso de empuje; Git no permitirá que los usuarios se sobrescriban entre sí. Digamos que John y Jessica empiezan a trabajar al mismo tiempo. John termina su cambio y lo empuja al servidor. Entonces Jessica intenta empujar sus cambios, pero el servidor los rechaza. Le dice que está tratando de empujar cambios no rápidos y que no podrá hacerlo hasta que busque y se fusione. Este flujo de trabajo es atractivo para mucha gente porque es un paradigma con el que muchos están familiarizados y cómodos.

Esto tampoco se limita a los equipos pequeños. Con el modelo de ramificación de Git, es posible que cientos de desarrolladores trabajen con éxito en un único proyecto a través de docenas de ramas simultáneamente.

Flujo de Trabajo Administrador-Integración

Debido a que Git permite tener múltiples repositorios remotos, es posible tener un flujo de trabajo donde cada desarrollador tenga acceso de escritura a su propio repositorio público y acceso de lectura a todos los demás. Este escenario a menudo incluye un repositorio canónico que representa el proyecto "oficial". Para contribuir a ese proyecto, creas tu propio clon público del proyecto y haces pull con tus cambios. Luego, puede enviar una solicitud al administrador del proyecto principal para que agregue los cambios. Entonces, el administrador agrega el repositorio como remoto, prueba los cambios localmente, los combina en su rama y los envía al repositorio. El proceso funciona de la siguiente manera. (ver Flujo de Trabajo Administrador-Integración.):

1. El administrador del proyecto hace un push al repositorio público.

2. El contribuidor clona ese repositorio y realiza los cambios.

3. El contribuidor realiza un push con su copia pública del proyecto.

4. El contribuidor envía un correo electrónico al administrador pidiendo que haga pull de los cambios.

5. El administrador agrega el repositorio del contribuidor como remoto y fusiona ambos localmente.

6. El administrador realiza un push con la fusión del código al repositorio principal.

Figure 2. Flujo de Trabajo Administrador-Integración.

Este es un flujo de trabajo muy común con herramientas basadas en hubs como GitHub o GitLab, donde es fácil hacer un fork de un proyecto e introducir los cambios en este fork para que todos puedan verlos. Una de las principales ventajas de este enfoque es que el contribuidor puede continuar realizando cambios y el administrador principal del repositorio puede incorporar los cambios en cualquier momento. Los contribuidores no tienen que esperar a que el proyecto incorpore sus cambios; cada parte puede trabajar a su propio ritmo.

Flujo de Trabajo Dictador-Tenientes

Esta es una variante de un flujo de trabajo de múltiples repositorios. Generalmente es utilizado por grandes proyectos con cientos de colaboradores; Un ejemplo famoso es el kernel de Linux. Varios administradores de integración están a cargo de ciertas partes del repositorio. Se les llaman tenientes''. Todos los tenientes tienen un gerente de integración conocido como el dictador benévolo''. El repositorio del dictador benevolente sirve como el repositorio de referencia del cual todos los colaboradores necesitan realizar pull. El proceso funciona así. (ver Flujo de Trabajo Dictador Benevolente.):

1. Los desarrolladores trabajan en su propia rama especifica y fusionan su código en la rama master, la cual, es una copia de la rama del dictador.

2. Los tenientes fusionan el código de las ramas master de los desarrolladores en sus ramas master de tenientes.

3. El dictador fusiona la rama master de los tenientes a su rama master de dictador.

4. El dictador hace push del contenido de su rama master al repositorio para que otros fusionen los cambios a sus ramas.

Figure 3. Flujo de Trabajo Dictador Benevolente.

Este tipo de flujo de trabajo no es común, pero puede ser útil en proyectos muy grandes o en entornos altamente jerárquicos. Permite al líder del proyecto (el dictador) delegar gran parte del trabajo y recopilar grandes subconjuntos de código en múltiples puntos antes de integrarlos.

Resumen de Flujos de Trabajo

Estos son algunos de los flujos de trabajo de uso común que son posibles con un sistema distribuido como Git, pero se puede observar que hay muchas posibles variaciones que buscan adaptarse a tu flujo de trabajo particular. Ahora puedes (con suerte) determinar qué combinación de flujo de trabajo puede funcionar mejor para ti, cubriremos algunos ejemplos más específicos sobre cómo cumplir los roles principales que conforman los diferentes flujos. En la siguiente sección, aprenderás sobre algunos patrones comunes para contribuir a un proyecto.