Close

Flujo de trabajo de bifurcación

El flujo de trabajo de bifurcación es radicalmente diferente a otros flujos de trabajo populares de Git. En lugar de usar un único repositorio en servidor para que actúe como código base "central", proporciona a cada desarrollador su propio repositorio en servidor. De esta forma, cada colaborador tiene dos repositorios de Git: uno local y privado, y otro público y en servidor. El flujo de trabajo de bifurcación se ve con mayor frecuencia en proyectos públicos de código abierto.

La principal ventaja del flujo de trabajo de bifurcación es que las contribuciones se pueden integrar sin que sea necesario que todo el mundo envíe los cambios a un único repositorio central. Los desarrolladores envían los cambios a sus propios repositorios en servidor y solo el mantenedor del proyecto puede enviar al repositorio oficial. Esto permite al mantenedor aceptar confirmaciones de cualquier desarrollador sin darle acceso de escritura al código base oficial.

El flujo de trabajo de bifurcación suele seguir un modelo de ramificación basado en el flujo de trabajo de Gitflow. Esto significa que las ramas de función completas se utilizarán para la fusión en el repositorio original del responsable del proyecto. El resultado es un flujo de trabajo distribuido que proporciona una forma flexible de que los equipos grandes y orgánicos (incluidos los terceros que no sean de confianza) colaboren de forma segura. Esto también lo convierte en un flujo de trabajo ideal para proyectos de código abierto.


Funcionamiento


Como en los demás flujos de trabajo de Git, el flujo de trabajo de bifurcación comienza con un repositorio público oficial almacenado en un servidor. La diferencia es que, cuando un nuevo desarrollador quiere empezar a trabajar en el proyecto, no clona directamente el repositorio oficial.

Lo que se hace es bifurcar el repositorio oficial para crear una copia en el servidor. Esta nueva copia sirve como su repositorio público personal; ningún otro desarrollador puede enviar cambios a ese repositorio, pero puede incorporarlos (pronto veremos por qué esto es importante). Después de haber creado su copia en servidor, el desarrollador realiza un git clone para obtener una copia en su equipo local. Esto actúa como un entorno de desarrollo privado, al igual que en los otros flujos de trabajo.

Cuando está listo para publicar una confirmación local, la envía a su propio repositorio público, no al oficial. Luego, presenta una solicitud de incorporación de cambios en el repositorio principal, lo que informa al mantenedor del proyecto de que hay una actualización lista para integrarse. La solicitud de incorporación de cambios también sirve como un práctico hilo de debate si hay problemas con el código aportado. A continuación, se muestra un ejemplo paso a paso de este flujo de trabajo.

Ventana de consola
Material relacionado

Git log avanzado

Logotipo de Bitbucket
VER LA SOLUCIÓN

Aprende a usar Git con Bitbucket Cloud

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.

Bifurcación frente a clonación


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.

Crear ramas en un flujo de trabajo de bifurcación


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.

Bifurca un repositorio


Ilustración del repositorio

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.

Clonar la bifurcación


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:

git clone https://user@bitbucket.org/user/repo.git

Añadir un repositorio remoto


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.

git remote add upstream https://bitbucket.org/maintainer/repo

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:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

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

Trabajar en una rama: hacer y enviar cambios


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:

git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"

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:

git pull upstream main

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.

Realizar una pull request


Ilustración del repositorio

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:

git push origin feature-branch

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.

Resumen


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.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Gente que colabora utilizando un muro lleno de herramientas

Blog de Bitbucket

Ilustración de Devops

Ruta de aprendizaje de DevOps

Demostraciones de funciones con expertos de Atlassian del Centro de demostraciones

Cómo funciona Bitbucket Cloud con Atlassian Open DevOps

Suscríbete para recibir el boletín de DevOps

Thank you for signing up