Basándose en el modelo de rama de características, las principales plataformas de Git han ampliado el flujo de trabajo para incluir solicitudes de fusión/extracción como partes integrales.

La principal mejora (en comparación con el flujo de trabajo de la rama de funciones) es el proceso de revisión obligatorio. Analicemos un escenario para mostrar las solicitudes de combinación y extracción. Un desarrollador, Manuel, desarrolla una nueva función. Lo hace creando un característica-1 rama y agregando dos confirmaciones (a8503d6 y 70996c6). Al empujar al repositorio remoto, Manuel recibe la siguiente respuesta:

git push --set-upstream origin feature-1

 

   Enumerating objects: 7, done.

   ...

   remote:

   remote: To create a merge request for feature-1, visit:

   remote: https://gitlab.com/git-compendium/workflows-github...

   remote:

   To gitlab.com:git-compendium/workflows-github.git

     * [new branch] feature-1 -> feature-1

   Branch 'feature-1' set up to track remote branch 'feature-1'...

Las líneas que comienzan con remoto indicar la respuesta del Git servidor. En terminales modernas en Linux y macOS, puede hacer clic en el enlace directamente (posiblemente juntos manteniendo presionado (Control)). Alternativamente, puede crear la solicitud de combinación a través de la interfaz web.

Manuel crea la solicitud de fusión a través de la interfaz web e ingresa el nombre «Solicitud de fusión de función 1». Tenga en cuenta que esta solicitud de combinación no es una característica de Git en sí, y no encontrará una referencia a esta solicitud en ninguna parte a través de registro de git. Los metadatos sobre la solicitud de combinación, como quién creó la solicitud y cuándo, se almacenan en la base de datos del proveedor de alojamiento de Git. Si cambia de proveedor en algún momento, es probable que esta información se pierda. Una excepción encomiable es GitLabque puede importar tanto las solicitudes de extracción de GitHub como las de Gitea, incluidos los comentarios, tal como se verificó durante las pruebas.

Manuel ingresa a Jane como la persona responsable de la solicitud de fusión. Jane revisa la nueva función y solicita documentación adicional para la nueva función. Manuel agrega el comentario y confirma los cambios (commit e029614). Luego, la versión de la rama de funciones se instala en un sistema de prueba. Cuando el equipo de control de calidad (QA) no plantea objeciones a la nueva función, Jane fusiona los cambios en el principal rama.

El flujo de trabajo que hemos descrito ciertamente se usa ampliamente, sobre todo debido a la popularidad de GitHub y GitLab. Los procesos no son complicados y la revisión del código puede eliminar errores antes de que lleguen a la rama principal. El flujo de trabajo hereda el problema de las ramas que se ejecutan en paralelo durante demasiado tiempo cuando las funciones son demasiado grandes del modelo de ramas de funciones. Puede surgir un problema adicional con este flujo de trabajo si el intervalo de tiempo entre la solicitud de extracción/fusión y la fusión en sí es demasiado largo. Los motivos de este retraso pueden ser que la revisión del código no se lleve a cabo lo suficientemente rápido o que se encuentren demasiados problemas durante la solicitud de incorporación de cambios. Ambos extienden el tiempo de ejecución paralelo de las sucursales.

A diferencia de la sección anterior, es posible que observe algunos cambios en el flujo de trabajo. Queríamos resaltar la diferencia entre el flujo de trabajo puramente basado en Git y el flujo de trabajo presentado en esta sección, que solo se puede implementar con servidores Git apropiados.

tenedores

Puede tenedor repositorios extranjeros usando Git. En combinación con las solicitudes de fusión/extracción, también puede establecer un flujo de trabajo en el que todos los desarrolladores administren sus propios repositorios a los que solo ellos tienen acceso de escritura.

Este enfoque está cerca de la idea original de Linus Torvalds. El inventor de Git, que había desarrollado el software principalmente para administrar el kernel de Linux, recibió una serie de sugerencias de mejoras en forma de archivos de parches como archivos adjuntos de correo electrónico a la lista de correo del kernel. Para ahorrarse el trabajo de incorporar y probar los parches, Torvalds sugirió que los desarrolladores de parches mantengan sus propios repositorios Git donde puedan incorporar y probar sus propios parches. Dado que GitHub no existía en ese entonces, los desarrolladores tenían que ejecutar sus propios servidores Git, desde los cuales Torvalds podía extraer, que es exactamente lo que el servidor integrado de Git demonio git es para.

En una charla técnica que vale la pena ver, Torvalds presentó su motivación para crear Git en 2007, cuando solo tenía dos años. A su manera bastante obstinada, condenó todos los demás sistemas de control de versiones, en primer lugar Apache Subversion (SVN), que era el sistema más utilizado en ese momento: https://www.youtube.com/watch?v=4XpnKHJAok8.

Las bifurcaciones con solicitudes de extracción/fusión son un flujo de trabajo extremadamente útil para contribuciones ocasionales de diferentes personas en los proyectos de otras personas. Sin embargo, con una cantidad manejable de miembros en su equipo que están registrados con el equipo de alguna manera y que tienen permisos para acceder a un repositorio central, es probable que no necesite bifurcaciones para su proyecto en este caso.

Conclusión

Algunas ventajas de usar solicitudes de fusión/extracción incluyen las siguientes:

• Revisión de código antes de fusionarse en la rama principal
• Buena documentación de los procesos de trabajo.
• Rama principal estable

Algunos inconvenientes de usar solicitudes de fusión/extracción incluyen los siguientes:

• Ramas paralelas cuando las revisiones de código son demasiado lentas

Nota del editor: esta publicación ha sido adaptada de una sección del Git: Gestión de proyectos para desarrolladores y equipos DevOps de Bernd Öggl y Michael Kofler.