Flujo de trabajo de bifurcación

1. Un desarrollador "bifurca" un repositorio"oficial" en servidor. Esto crea su propia copia en servidor.

2. La nueva copia en servidor se clona en su sistema local.

3. Se añade una ruta remota de Git para el repositorio "oficial" al clon local.

4. Se crea una nueva rama de función local.

5. El desarrollador hace cambios en la nueva rama.

6. Se crean nuevas confirmaciones para los cambios.

7. La rama se envía a la copia en servidor del desarrollador.

8. El desarrollador abre una solicitud de incorporación de cambios desde la nueva rama al repositorio "oficial".

9. La solicitud de incorporación de cambios se aprueba para la fusión y se hace la fusión en el repositorio en servidor original.

Para integrar la función en el código base oficial, el mantenedor incorpora los cambios del colaborador en su repositorio local, comprueba que no causen problemas en el proyecto, los fusiona en su rama main local y luego envía la rama main al repositorio oficial en servidor. La contribución ahora forma parte del proyecto y los demás desarrolladores deben incorporarla desde el repositorio oficial para sincronizar sus repositorios locales.

Es importante entender que la noción de repositorio "oficial" de un flujo de trabajo de bifurcación no es más que una convención. De hecho, lo único que hace "oficial" al repositorio es que es el repositorio público del mantenedor del proyecto.

Es importante tener en cuenta que los repositorios "bifurcados" y las "bifurcaciones" no son operaciones especiales. Los repositorios bifurcados se crean con el comando git clone estándar, normalmente son clones del repositorio en servidor y, por lo general, se gestionan y están alojados con un servicio Git de terceros como Bitbucket. No existe un comando Git único para crear repositorios bifurcados. Una operación de clonación es básicamente una copia de un repositorio y su historial.

Todos estos repositorios públicos personales son solo una forma práctica de compartir ramas con otros desarrolladores. Todo el mundo debe seguir usando ramas para aislar las funciones, al igual que en el flujo de trabajo de ramas de función y el flujo de trabajo de Gitflow. La única diferencia es cómo se comparten esas ramas. En el flujo de trabajo de bifurcación, se incorporan al repositorio local de otro desarrollador, mientras que en la rama de función y los flujos de trabajo de Gitflow se envían al repositorio oficial.

Todos los desarrolladores nuevos de un proyecto de flujo de trabajo de bifurcación deben bifurcar el repositorio oficial. Como hemos indicado anteriormente, la bifurcación no es más que una operación git clone estándar. Para llevarla a cabo, debe utilizarse el protocolo SSH en el servidor y ejecutar git clone para copiar el repositorio en otra ubicación del servidor. Los populares servicios de alojamiento de Git, como Bitbucket, ofrecen funciones de bifurcación de repositorios que automatizan este paso.

Todos los desarrolladores nuevos de un proyecto de flujo de trabajo de bifurcación deben bifurcar el repositorio oficial. Como hemos indicado anteriormente, la bifurcación no es más que una operación git clone estándar. Para llevarla a cabo, debe utilizarse el protocolo SSH en el servidor y ejecutar git clone para copiar el repositorio en otra ubicación del servidor. Los populares servicios de alojamiento de Git, como Bitbucket, ofrecen funciones de bifurcación de repositorios que automatizan este paso.

Suponiendo que se esté usando Bitbucket para alojar estos repositorios, los desarrolladores de un proyecto deben tener su propia cuenta de Bitbucket y clonar su copia bifurcada del repositorio con esta operación:

Mientras que otros flujos de trabajo de Git usan un único control remoto de origen que apunta al repositorio central, el flujo de trabajo de bifurcación requiere dos controles remotos: uno para el repositorio oficial y otro para el repositorio personal del lado del servidor del desarrollador. Si bien puedes llamar a estos controles remotos como quieras, una convención habitual es usar origin como el remoto para tu repositorio bifurcado (esto se creará automáticamente cuando ejecutes git clone) y en sentido ascendente para el repositorio oficial.

Deberás crear el control remoto ascendente tú mismo con el comando anterior. De esta forma podrás mantener tu repositorio local actualizado fácilmente a medida que avance el proyecto oficial. Ten en cuenta que si tu repositorio ascendente tiene habilitada la autenticación (es decir, no es de código abierto), tendrás que proporcionar un nombre de usuario, como este:

Esto requiere que los usuarios proporcionen una contraseña válida antes de incorporar cambios en el código base oficial o de clonarlo.

El desarrollador del repositorio bifurcado puede editar el código, confirmar los cambios y crear ramas en la copia local, como pasa con otros flujos de trabajo de Git:

Todos los cambios serán totalmente privados hasta que los envíe al repositorio público. Y, si el proyecto oficial ha avanzado, podrá acceder a las nuevas confirmaciones con git pull:

El hecho de que los desarrolladores deban trabajar en una rama de función exclusiva generalmente resulta en una fusión con avance rápido.

Una vez que un desarrollador lo tiene todo listo para compartir su nueva función, debe hacer dos cosas. Primero tiene que enviarla al repositorio público para que otros desarrolladores puedan acceder a ella. Como el remoto origin ya debe estar configurado, solo habrá que hacer esto:

Esto difiere de los otros flujos de trabajo por el hecho de que el remoto origin apunta al repositorio en servidor personal del desarrollador, no al código base principal.

En segundo lugar, debe informar al mantenedor del proyecto de que quiere fusionar su función en el código base oficial. Bitbucket incluye un botón de "solicitud de incorporación de cambios" que lleva a un formulario en el que debe especificarse la rama que se quiere fusionar en el repositorio oficial. Lo habitual es querer integrar la rama feature en la rama main del remoto upstream.

En resumen, el flujo de trabajo de bifurcación se usa habitualmente en proyectos públicos de código abierto. La bifurcación es una operación git clone que se ejecuta en una copia en servidor de un repositorio de proyectos. Los flujos de trabajo de bifurcación suelen combinarse con un servicio de alojamiento de Git como Bitbucket. Este es un ejemplo a grandes rasgos de un flujo de trabajo de bifurcación:

1. Quieres contribuir a una biblioteca de código abierto alojada en bitbucket.org/usuarioA/open-project.

2. Con Bitbucket, creas una bifurcación del repositorio en bitbucket.org/TuNombre/open-project.

3. En tu sistema local, ejecutas git clone en https://bitbucket.org/TuNombre/open-project para obtener una copia local del repositorio.

4. Creas una nueva rama feature en tu repositorio local.

5. Terminas con la nueva función y ejecutas git commit para guardar los cambios.

6. A continuación, envías la nueva rama feature a tu repositorio bifurcado remoto.

7. Con Bitbucket, abres una solicitud de incorporación de cambios en el repositorio original para la nueva rama en bitbucket.org/usuarioA/open-project.

Con un flujo de trabajo de bifurcación, el mantenedor de un proyecto puede abrir el repositorio a las contribuciones de cualquier desarrollador sin tener que gestionar manualmente la autorización de cada colaborador. Esto ofrece al mantenedor un flujo de trabajo similar a las incorporaciones de cambios. El flujo de trabajo de bifurcación se utiliza sobre todo en proyectos de código abierto, pero también se puede aplicar a flujos de trabajo de empresas privadas para tener un mayor control sobre lo que se fusiona en una publicación. Esto puede ser práctico en equipos que cuentan con gestores de implementación o ciclos de publicación estrictos.

¿No sabes qué flujo de trabajo es el más adecuado para ti? Consulta nuestra página de comparación de flujos de trabajo de Git.