5.1 Git en entornos distribuidos - Flujos de trabajo distribuidos

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.

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.

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.):

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.

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.):

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.

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.