Exploración del flujo de trabajo de bifurcación
El flujo de trabajo de bifurcación es fundamentalmente diferente al de otros flujos de trabajo populares de Git.
En lugar de usar un único repositorio del lado servidor para actuar como el código base "central", proporciona a todos los desarrolladores su repositorio del lado servidor.
Significa que cada colaborador tiene dos repositorios de Git:
- Un local privado.
- Un servidor público.
El flujo de trabajo de bifurcación se ve con más frecuencia en proyectos de código abierto públicos.
La principal ventaja del flujo de trabajo de bifurcación es que las contribuciones se pueden integrar sin necesidad de que todos suban a un repositorio central.
Los desarrolladores insertan en sus repositorios del lado servidor y solo el mantenedor del proyecto puede insertar en el repositorio oficial.
Permite al mantenedor aceptar confirmaciones de cualquier desarrollador sin concederles acceso escrito al código base oficial.
El flujo de trabajo de bifurcación está destinado a integrarse en el repositorio del mantenedor del proyecto original.
El resultado es un flujo de trabajo distribuido que proporciona una manera flexible de que los equipos orgánicos grandes (incluidos terceros que no son de confianza) colaboren de forma segura.
Esto también lo convierte en un flujo de trabajo ideal para proyectos de código abierto.
Cómo funciona
Como en los otros flujos de trabajo de Git, el flujo de trabajo de bifurcación comienza con un repositorio público oficial almacenado en un servidor.
Pero cuando un nuevo desarrollador quiere empezar a trabajar en el proyecto, no clona directamente el repositorio oficial.
En su lugar, realizan un fork del repositorio oficial para crear una copia de este en el servidor.
Esta nueva copia actúa como su repositorio público personal: ningún otro desarrollador puede insertarlo, pero puede extraer los cambios de ella (veremos por qué esto es necesario en un momento).
Después de crear su copia del lado servidor, el desarrollador realiza un clon de Git para obtener una copia de él en su equipo local.
Actúa como su entorno de desarrollo privado, al igual que en los otros flujos de trabajo.
Cuando estén listos para publicar una confirmación local, insertan la confirmación en su repositorio público, no en la oficial.
A continuación, envían una solicitud de extracción al repositorio principal, lo que permite al mantenedor del proyecto saber que una actualización está lista para integrarse.
Un pull request también sirve como un hilo de discusión conveniente si hay problemas con el código contribuido.
A continuación se muestra un ejemplo paso a paso de este flujo de trabajo:
- Un desarrollador "hace un fork" de un repositorio de servidor "oficial". Crea su copia del lado servidor.
- La nueva copia del lado servidor se clona en su sistema local.
- Se agrega una ruta de acceso remota de Git para el repositorio "oficial" al clon local.
- Se crea una nueva rama de características locales.
- El desarrollador realiza cambios en la nueva rama.
- Se crean nuevas confirmaciones para los cambios.
- La rama se inserta en la copia del lado servidor del desarrollador.
- El desarrollador abre una solicitud de incorporación de cambios de la nueva rama al repositorio "oficial".
- La solicitud de incorporación de cambios se aprueba para la combinación y se integra en el repositorio original del lado del servidor.
Para integrar la característica en el código base oficial:
- El mantenedor integra los cambios del colaborador en su repositorio local.
- Comprueba que no interrumpa el proyecto.
- Se fusiona con su rama principal local.
- Inserta la rama principal en el repositorio oficial del servidor.
La contribución forma parte del proyecto y otros desarrolladores deben extraer del repositorio oficial para sincronizar sus repositorios locales.
Es esencial comprender que la noción de un repositorio "oficial" en el flujo de trabajo de bifurcación es simplemente una convención.
Lo único que hace que el repositorio oficial sea oficial es que es el repositorio del mantenedor del proyecto.
Bifurcación versus clonación
Es esencial tener en cuenta que los repositorios "bifurcados" y el "bifurcar" no son operaciones especiales.
Los repositorios bifurcadas se crean mediante el comando de clonación de Git estándar. Los repositorios bifurcados suelen ser "clones del lado servidor" administrados y hospedados por un proveedor de servicios de Git, como Azure Repos.
No hay ningún comando git único para crear repositorios bifurcados.
Una operación de clonación es básicamente una copia de un repositorio y su historial.