Exploración del flujo de trabajo de bifurcación
El flujo de trabajo de bifurcación es muy diferente de otros flujos de trabajo de Git populares.
En lugar de usar un único repositorio del lado servidor para que actúe como código base "central", proporciona a cada desarrollador un repositorio del lado servidor.
Esto significa que cada colaborador tiene dos repositorios de Git:
- Uno privado local
- Uno público del lado servidor
El flujo de trabajo de bifurcación es más frecuente 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 todo el mundo haga una inserción en un único repositorio central.
Los desarrolladores envían sus repositorios del lado servidor y solo el encargado del mantenimiento del proyecto puede realizar la inserción en el repositorio oficial.
Esto permite al encargado del mantenimiento aceptar confirmaciones de cualquier desarrollador sin concederle acceso de escritura al código base oficial.
Normalmente, el flujo de trabajo de bifurcación se destina a combinar en el repositorio del responsable de mantenimiento del proyecto original.
El resultado es un flujo de trabajo distribuido que proporciona un método flexible para que los equipos orgánicos grandes (incluidos los de 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.
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, bifurca el repositorio oficial para crear una copia en el servidor.
Esta nueva copia sirve como repositorio público personal; es decir, ningún otro desarrollador puede insertar en él, pero sí puede extraer cambios de él (dentro de un momento veremos por qué es necesario).
Una vez que ha creado la copia del lado servidor, el desarrollador realiza una clonación de Git para obtener una copia en su equipo local.
Esto sirve como su entorno de desarrollo privado, al igual que en los demás flujos de trabajo.
Cuando está listo para publicar una confirmación local, envía la confirmación a su repositorio público, y no al oficial.
Después, archiva una solicitud de incorporación de cambios con el repositorio principal, lo que permite al encargado de mantenimiento del proyecto saber que hay una actualización lista para su integración.
La solicitud de incorporación de cambios también sirve como un práctico hilo de discusión si hay problemas con el código aportado.
A continuación se muestra un ejemplo paso a paso de este flujo de trabajo:
- Un desarrollador bifurca un repositorio oficial del lado servidor. Crea una copia del lado servidor.
- La nueva copia del lado servidor se clona en su sistema local.
- Se agrega al clon local una ruta de acceso remota de Git para el repositorio oficial.
- Se crea una rama de características local.
- El desarrollador realiza cambios en la nueva rama.
- Se crean 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 desde la nueva rama al repositorio oficial.
- La solicitud de incorporación de cambios se aprueba para la combinación y se combina en el repositorio original del lado servidor.
Para integrar la característica en el código base oficial:
- El encargado del mantenimiento incorpora los cambios del colaborador en su repositorio local.
- Comprueba que no se interrumpirá el proyecto.
- Lo combina en su rama principal local.
- Inserta la rama principal en el repositorio oficial del servidor.
La contribución ahora forma parte del proyecto y otros desarrolladores deben realizar la extracción 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 tan oficial es que es el repositorio del encargado del mantenimiento del proyecto.
Bifurcación frente a clonación
Es esencial tener en cuenta que los repositorios bifurcados y la bifurcación no son operaciones especiales.
Los repositorios bifurcados se crean mediante el comando estándar git clone. 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 de Git único para crear repositorios bifurcados.
Una operación de clonación es básicamente una copia de un repositorio y su historial.