Si eres un desarrollador en solitario que trabaja en tus propios proyectos, tu flujo de trabajo en Git suele ser sencillo: Trabajas en la rama principal (o maestra) todo el día, todos los días.
Probablemente sepas que los equipos de desarrolladores profesionales no trabajan así. Múltiples desarrolladores trabajando en la rama principal pueden convertirse rápidamente en un caos. Y es probable que el código no revisado o no probado llegue a producción.
Los equipos profesionales utilizan procesos y flujos de trabajo para evitar que esto ocurra. Y el flujo de trabajo de Git más comúnmente utilizado en los equipos de desarrolladores.
Desarrollo basado en el tronco (o, más correctamente, desarrollo basado en el tronco escalado).
Si tu objetivo es encontrar un trabajo como desarrollador profesional, es recomendable encarecidamente que te acostumbres a este flujo de trabajo por adelantado. Cuanto más sepas trabajar como un profesional, menos te sentirás abrumado en tu primer trabajo. No es muy difícil si conoces los fundamentos de Git. Pero hay mucho glosario a su alrededor que puede confundirte al principio.
Índice de contenidos
1. El desarrollo basado en el tronco en pocas palabras
2. Protección de ramas: Imponer el uso de solicitud de extracción
3. Un recorrido por el flujo de trabajo del desarrollo basado en troncos
3.1 - Abrir una solicitud de extracción
3.2 - Canalización de la integración continua
3.3 - Comentarios sobre el código
3.4 - Tratamiento de los comentarios de la revisión
3.5 - Aprobación de una solicitud de extracción
3.6 - Fusión de la solicitud de extracción
3.7 - La historia de la rama principal
3.8 - Actualización de la rama principal local
4. Resumen
El desarrollo basado en el tronco en pocas palabras
- Revisa una nueva rama desde la rama principal.
- Confirme su código en esta rama y envíelo al repositorio de GitHub.
- Abres una solicitud de extracción (o solicitud de fusión como lo llama GitLab).
- Las pruebas automatizadas verifican que la aplicación se comporta como se espera.
- Un compañero de equipo revisa tu código y tú lo ajustas según los comentarios.
- Usted fusiona su rama en la rama principal a través de la solicitud de extracción.
¿Qué es una solicitud de extracción?
El nombre de solicitud de extracción en GitHub es confuso. GitLab lo llama solicitud de fusión, que es mucho más descriptivo. Básicamente, una solicitud de extracción es una forma de pedir permiso para fusionar tu código en la rama principal:
"Hola equipo, ¿puede alguien echar un vistazo a este código y decirme si es bueno? Me gustaría llevarlo a la rama principal para que nuestros usuarios puedan beneficiarse de él."
Puedes pensar en una solicitud de extracción como una función encima de una rama de Git que te permite obtener comentarios de tus compañeros de equipo. Y, como se ha mencionado, también te permite ejecutar automáticamente comprobaciones y pruebas en tus cambios de código antes de que pasen a la rama principal.
En resumen, las solicitudes de extracción son:
- Un mecanismo para recoger opiniones y así aumentar la calidad del código
- Una herramienta para ejecutar la automatización (por ejemplo, pruebas) en su código para disminuir el riesgo de introducir errores en el código de producción.
Protección de ramas: Imponer el uso de la solicitud de extracción
Los procesos y los flujos de trabajo son estupendos. Pero la gente es perezosa y busca soluciones. Así que lo ideal es obligar a todos los miembros del equipo a utilizar la solicitud de extracción en lugar de comprometerse directamente con la rama principal.
Por suerte, GitHub nos cubre la espalda con una función llamada "protección de rama". Para proteger la rama principal abre la configuración de tu repositorio en GitHub, selecciona "Ramas" en el menú de la izquierda y haz clic en el botón "Añadir regla".
Algunas notas sobre las normas seleccionadas:
- En un equipo de desarrolladores se activa mayoritariamente la opción "Requerir una solicitud de extracción antes de fusionar" → "Requerir aprobaciones". De esta manera podemos imponer que los desarrolladores revisen y aprueben el código de los demás. Esta es una salvaguarda contra nuevos errores e idealmente aumenta la calidad y coherencia del código.
- La opción "Requerir historial lineal" no es necesaria, pero por mi experiencia muchos equipos la utilizan hoy en día. Evita que se realicen confirmaciones de fusión en la rama correspondiente. En su lugar, tienes que "aplastar y fusionar" una solicitud de extracción o "Rebase".
- La opción "Incluir a los administradores" es importante si quieres aplicar el flujo de trabajo para ti en tus propios repositorios. Dado que usted es el administrador, las reglas no se aplicarían a usted de otro modo.
Si un desarrollador crea ahora una confirmación en la rama principal e intenta enviarla, verá un mensaje de error.
Un recorrido por el flujo de trabajo del desarrollo basado en el tronco
Abrir una solicitud de extracción
Ahora escribimos nuestro código, lo confirmamos y lo enviamos al repositorio remoto en GitHub.
En GitHub, deberías ver ahora un banner para crear una solicitud de extracción.
Una vez que haga clic en el botón, verá un formulario en el que puede introducir un título y una descripción. A continuación, haz clic en el botón "Crear solicitud de extracción".
¡Felicidades, has abierto tu primera solicitud de extracción! Esto es lo que debería ver ahora:
Tubería de integración continua
¿Se ha fijado en las comprobaciones de estado al final del botón?
Esta es una característica muy útil. Puedes ejecutar scripts como npm run lint o npm run test dentro de tus solicitudes de extracción para disminuir el riesgo de introducir errores. Esto se llama una tubería de integración continua.
Revisión del código
En un equipo del mundo real, el código suele ser revisado por al menos un compañero de equipo. Esto también previene los errores y ayuda a mantener el código base limpio y consistente. Una solicitud de extracción es también una gran manera de discutir tu código en caso de que estés atascado.
Como ejemplo se muestra otra cuenta con acceso al repositorio. De esta manera así es como nuestro compañero de equipo imaginario revisaría tu código.
Nuestro compañero de equipo puede añadir comentarios al código.
Por último, presentan la revisión.
Como autor de la solicitud de extracción, ahora podemos ver los comentarios.
Manejo de los comentarios de revisión
Ahora tenemos dos opciones: podemos actualizar nuestro código según los comentarios o iniciar una discusión. Para ajustar nuestro código simplemente volvemos a nuestra máquina local, cambiamos el código, lo confirmamos y lo enviamos. Puedes ver la confirmación nueva debajo de los comentarios de revisión. También puedes añadir un comentario y resolver la conversación.
Por último, puede solicitar una nueva revisión:
Aprobación de una solicitud de extracción
Una vez que tu compañero de equipo esté satisfecho, puede aprobar tu solicitud de extracción enviando una revisión. Puede añadir un comentario o emoji afirmativo como confirmación de la aprobación.
Fusionar la solicitud de extracción
Finalmente, es el momento de fusionar nuestro solicitud de extracción. Ahora nuestros cambios en el código se añadirán a la rama principal.
¿Recuerdas que se estableció la opción "Requerir historial lineal" en nuestras reglas de protección de ramas? Por eso vemos un botón "Aplastar y fusionar" en lugar de un simple botón "Fusionar" por defecto.
Veamos qué ocurre cuando se pulsa el botón:
Y una vez que pulsamos el botón de confirmación ya está todo listo.
La historia de la rama principal
Todavía no se ha explicado lo que hace el botón "Aplastar y fusionar", ¿verdad? La solicitud de extracción (o nuestra rama Git) contenía múltiples confirmaciones:
Cuando miramos el historial de confirmación de nuestra rama principal ya no vemos estas confirmaciones. En su lugar, sólo hay una única confirmación que apunta a la solicitud de extracción (a través del enlace #6):
Todos las confirmaciones de nuestra rama original han sido aplastados en una solo confirmación. El beneficio aquí es que no necesitas mantener las aprobaciones en la solicitud de extracción súper ordenados. Por ejemplo, las confirmaciones que son simples correcciones durante el proceso de revisión como "Eliminar el nombre de la clase no utilizada" no necesitan realmente aparecer en la historia de la rama principal.
Actualización de la rama principal local
Como último paso (que es fácil de olvidar) sincronizamos nuestra rama principal local con el repositorio remoto. Dado que la fusión se ha realizado en GitHub, nuestra máquina local no conoce todavía los cambios en la rama principal.
Cuando trabajamos en un equipo de desarrolladores deberíamos hacer esto cada vez que empezamos a trabajar en una nueva rama.
Resumen
En este artículo has aprendido a configurar un repositorio de GitHub con protección de ramas para aplicar un popular flujo de trabajo de Git llamado Desarrollo Basado en Troncos.
¡Gracias por leer!
Obten el codigo utilizado aqui
Referencia:
Kettmann J. (2022,18 de marzo) Professional Git Workflow & GitHub Setup for (React) Developers