¿Qué es una solicitud de incorporación de cambios?

Una solicitud de incorporación de cambios (PR) es un método para proponer modificaciones en una base de código. Los desarrolladores de software crean una bifurcación del repositorio de código principal (también llamado “repo”) en una rama independiente, realizan confirmaciones de código en dicha rama a medida que trabajan y crean una solicitud de incorporación de cambios para señalar las modificaciones sugeridas con vistas a una revisión del código antes de incorporar o fusionar los cambios de la rama en la base de código principal.

Las PR son mecanismos habituales en repositorios Git como Bitbucket y GitHub. GitLab aplica el término “solicitud de fusión” en lugar de solicitud de incorporación de cambios para referirse al mismo proceso.

Los desarrolladores pueden crear solicitudes de incorporación de cambios mediante la interfaz de línea de comandos (CLI) o la interfaz web. Las nuevas solicitudes de incorporación de cambios suelen abrirse para la corrección de errores, actualizaciones de dependencias, nuevas características o código refactorizado. Las solicitudes de refactorizado agilizan las revisiones de código, mantienen las bases de código al día y fomentan la colaboración entre los miembros de los equipos de desarrollo de software.

Las PR permiten a los desarrolladores crear código fuente y probarlo localmente. Dado que los cambios en el código están aislados de la rama principal, los desarrolladores no tienen que preocuparse por romper toda la base de código.

La metodología de las solicitudes de incorporación de cambios implica tres roles fundamentales que se aplican principalmente a los proyectos de código abierto, pero que también pueden adoptarse en proyectos propietarios o de código cerrado:

• Mantenedores: los mantenedores del proyecto gestionan (y a menudo son propietarios) del proyecto y tienen la autoridad para aprobar y fusionar las PR o rechazarlas.

• Revisores: estos miembros del equipo (que pueden ser los propios mantenedores u otros colaboradores activos con mucha experiencia en el proyecto) revisan los cambios propuestos para comprobar en cuanto a la calidad del código y sugieren las mejoras según lo consideren oportuno.

• Colaboradores: estos desarrolladores tienen la tarea de realizar cambios y abrir solicitudes de incorporación de cambios.

La creación de solicitudes de incorporación de cambios suele implicar un procedimiento de siete pasos:

1. Un colaborador bifurca el repositorio principal para crear una nueva rama (utilizando el comando git checkout o la interfaz web) y clona dicha rama en su equipo local.
   
   
2. El colaborador trabaja en sus cambios y realiza una confirmación del código localmente en la rama.
   
   
3. Una vez que el colaborador ha terminado y probado su código, primero extrae las últimas actualizaciones del repositorio principal para evitar cualquier cambio conflictivo antes de enviar su código.
   
   
4. El colaborador abre una nueva solicitud de incorporación de cambios para que las modificaciones propuestas se integren en la rama principal.
   
   
5. Los revisores reciben notificaciones cuando se envían solicitudes de incorporación de cambios. Revisan la PR para comparar las diferencias (también conocidas como “diffs”) entre la rama del colaborador y la rama principal, revisando el código y comentando las áreas que necesitan optimización o mejora.
   
   
6. Los colaboradores realizan confirmaciones adicionales basadas en las sugerencias y solicitudes de cambio del revisor.
   
   
7. Cuando se han implementado todos los cambios, el revisor notifica al mantenedor, quien aprueba la PR. A continuación, la solicitud de incorporación de cambios se fusiona con el repositorio principal.

Los equipos de desarrollo de software pueden elegir entre varias opciones de flujo de trabajo de PR en función de sus necesidades. Entre los flujos de trabajo más habituales de solicitudes de incorporación de cambios se incluyen:

• Flujo de trabajo con rama de características

• Flujo de trabajo de bifurcación

• git-flow

• Flujo de trabajo apilado

Cada nueva característica cuenta su propia rama dedicada, con un nombre descriptivo que resalta su finalidad. Una vez completada la característica, los desarrolladores pueden enviar la rama de características a la rama principal y crear una solicitud de incorporación de cambios.

Este flujo de trabajo mantiene la estabilidad de la rama principal, ya que los colaboradores trabajan por separado en las características. Sin embargo, gestionar múltiples ramas de características puede resultar complicado.

El procedimiento de siete pasos descrito en la sección anterior sobre la creación de solicitudes de incorporación de cambios corresponde a un flujo de trabajo de bifurcación. Los proyectos de código abierto suelen emplear este flujo de trabajo, que también complementa las prácticas de integración continua/entrega continua (CI/CD). El flujo de GitHub sigue un proceso similar al flujo de trabajo de bifurcación.

El ingeniero de software Vincent Driessen formuló git-flow en 2010. Se utiliza habitualmente para desarrollar software con calendarios de lanzamiento rigurosos o que admita varias versiones.

Este flujo de trabajo sigue un modelo de ramificación compuesto por estas ramas:

• main contiene la última versión estable

• develop actúa como una rama de integración para correcciones de errores, características y otros cambios de código incluidos en la próxima versión

• feature utiliza develop como rama de origen y rama de destino, y las características se fusionan en develop cuando están listas

• release se bifurca desde develop y se etiqueta con el número de versión de la próxima versión, para luego fusionarse tanto en develop como en main una vez que está lista para su lanzamiento

• hotfix se bifurca directamente desde main para corregir cualquier problema de producción de alta prioridad o gravedad, y luego se fusiona tanto en develop como en main tan pronto como se completan las correcciones

Los desarrolladores crean solicitudes de incorporación de cambios para las ramas hotfix , feature y release que necesitan revisión.

Un flujo de trabajo apilado desglosa las tareas grandes en una secuencia de pequeños cambios de código incrementales. El siguiente cambio de código depende del anterior, por lo que las solicitudes de incorporación de cambios se crean una encima de la otra.

Considere una característica que implique cambios en estas funciones: la base de datos o el modelo de datos, la API y el front end. En el flujo de trabajo convencional de ramas de características o bifurcaciones, un colaborador debe esperar a que el la PR para los cambios en la base de datos o el modelo de datos sea revisada, aprobada y fusionada en la rama principal antes de poder comenzar con las actualizaciones de la API. En un flujo de trabajo apilado, este periodo de espera se elimina: el colaborador puede crear una rama a partir de los cambios en la base de datos o el modelo de datos para comenzar a trabajar en la API, enviar una PR para ello y crear una rama a partir de los cambios en la API para abordar tareas de front end.

Las solicitudes de incorporación de cambios ofrecen las siguientes ventajas:

• Fomentan la colaboración

• Mejoran la calidad del código

• Aumentan la transparencia

• Fortalecen las habilidades de codificación

Las solicitudes de incorporación de cambios fomentan la cooperación, animando a los miembros del equipo a trabajar juntos independientemente de su función. Las PR facilitan el feedback y su gestión, dan pie a debates y suscitan ideas para introducir mejoras.

Las PR inician el proceso de revisión del código, ayudando a detectar errores, desviaciones del estilo y las normas de codificación, problemas de rendimiento y vulnerabilidades de seguridad. Esta supervisión adicional mantiene o incluso mejora la calidad del código.

Las solicitudes de incorporación de cambios permiten a los equipos ver qué cambios se han implementado, quién los ha realizado, dónde se han aplicado y los motivos que los justifican. Esta visibilidad proporciona una mejor perspectiva del estado de la base de código y del propio proyecto.

Tanto los revisores como los colaboradores pueden aprender unos de otros, adquiriendo nuevas técnicas por el camino y descubriendo enfoques novedosos para los problemas. Los principiantes y los nuevos miembros del equipo también pueden estudiar las PR anteriores para comprender mejor la base de código y ponerse al día con las normas de codificación y buenas prácticas del equipo.

Aunque crear solicitudes de incorporación de cambios parece sencillo, aquí tiene algunos consejos y trucos que pueden facilitar aún más el proceso:

• Considere los borradores

• Los detalles importan

• Mantenga el enfoque

• Manténgase al día

• Utilice plantillas

Los borradores de solicitudes de incorporación de cambios o de fusión sirven como vía para que los desarrolladores compartan su trabajo en curso. Esto permite a los miembros del equipo comenzar a colaborar antes y solicita feedback más pronto, de modo que quienes se encuentren atascados en un problema puedan recabar posibles soluciones de sus compañeros de equipo.

Los desarrolladores deben proporcionar mensajes claros, concisos y específicos para sus nuevas confirmaciones. La claridad, la concisión y la especificidad también se aplican a los títulos y las descripciones de las PR, lo que facilita y agiliza a los revisores la comprensión de la intención detrás de los cambios en el código.

Agrupar varios problemas en una sola PR puede dar lugar a tiempos de revisión más largos y a más revisiones. Cada solicitud de incorporación de cambios debe abordar únicamente una corrección de error o una característica. Las solicitud de incorporación de cambios bien enfocadas pueden conducir a revisiones de código más eficientes.

Antes de enviar el código y abrir una PR, los desarrolladores deben asegurarse de que su rama esté actualizada. Incorporar los últimos cambios y cualquier nueva confirmación evita conflictos una vez que se fusiona la solicitud de incorporación de cambios. Pueden usar el comandogit pull para buscar y combinar los cambios de la rama de destino o el comandogit rebase para un historial de confirmaciones de git limpio.

Las plantillas de descripción de PR ayudan a garantizar la coherencia y proporcionan un contexto esencial para agilizar las revisiones de código. Los equipos pueden crear una plantilla para diferentes tipos de solicitudes de incorporación de cambios, como correcciones de errores, características o código refactorizado.

Las plantillas suelen escribirse utilizando el lenguaje de marcado Markdown y se colocan en la carpeta raíz o en la rama principal del repositorio del proyecto. Los campos típicos incluyen:

• Descripción del problema o la característica (con un enlace al tique correspondiente en Jira u otro software de seguimiento de incidencias como referencia)

• Solución que describe los cambios en el código con detalle

• Pruebas, como casos de pruebas unitarias o pruebas de integración, cobertura de pruebas y pasos para validar manualmente la solución, si procede

• Cambios de configuración

• Lista de verificación de tareas relevantes, como documentación del código y compilaciones de código limpio sin errores ni advertencias

La automatización de las PR puede acelerar el ciclo de vida de una solicitud de incorporación de cambios, desde su creación hasta su revisión y fusión. La automatización de las PR abarca una capa de sistemas que ayudan a aliviar los cuellos de botella:

• PR apiladas

• Pipelines de CI/CD

• Sistemas de gestión del SDLC

• Asistentes de codificación con IA

La mayoría de los repositorios Git no están diseñados para admitir un flujo de trabajo apilado, pero algunas herramientas eliminan la complejidad de sincronizar solicitudes de incorporación de cambios apiladas y gestionar conflictos de fusión. Entre estas herramientas se incluyen la plataforma Graphite, que cuenta con una CLI y una extensión para VS Code de Microsoft para PR apiladas, así como una interfaz web para gestionarlas; el sistema de gestión de código fuente Sapling de Meta; y la CLI de código abierto ghstack para enviar diferencias apiladas a GitHub como solicitudes de incorporación de cambios independientes.

Como flujo de trabajo automatizado de DevOps, el pipeline de CI/CD ayuda a garantizar la calidad del código. Plataformas como GitHub Actions y GitLab y otras herramientas de CI pueden ejecutar pruebas unitarias y pruebas de integración e implementar entornos de vista previa que actúan como entornos aislados para ver y probar cambios de código en las PR.

Los pipelines de CI/CD también refuerzan las prácticas de codificación segura. Los analizadores de código estático y otras herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) se integran de manera fluida con la mayoría de los entornos de CI/CD para identificar posibles vulnerabilidades en el código. Los equipos de DevOps pueden implementar hooks de pre-commit para la detección de secretos, lo que convierte el escaneo de secretos en un paso obligatorio antes de que los desarrolladores confirmen el código o inicien solicitudes de incorporación de cambios, y bloquea los cambios que contengan secretos codificados de forma rígida.

Plataformas como Jira e IBM® Engineering Lifecycle Management (ELM) admiten el seguimiento y la gestión de las solicitudes de incorporación de cambios a lo largo del ciclo de vida del desarrollo de software (SDLC).

Como parte de la suite ELM, IBM Engineering Workflow Management (EWM) e IBM Engineering Integration Hub integran la automatización de PR directamente en los flujos de trabajo de desarrollo. EWM puede conectarse con repositorios Git a través de los conectores del Hub y activar la creación de PR desde elementos de trabajo. Cuando se aprueba un requisito o una solicitud de cambio en EWM, una regla puede abrir automáticamente una solicitud de incorporación de cambios en el repositorio de Git vinculado y rellenar previamente la descripción.

Las automatizaciones impulsadas por IA en ELM también pueden ejecutar análisis estáticos y conjuntos de pruebas una vez que se abre la PR, publicar los resultados en el elemento de trabajo y bloquear la fusión hasta que se cumplan los criterios. Mientras tanto, el Hub sincroniza el estado de las PR en todas las herramientas, reflejándolo en el repositorio y en los paneles de control de EWM para una visibilidad en tiempo real.

Los asistentes de codificación con IA como GitHub Copilot e IBM Bob pueden complementar los flujos de trabajo de las solicitudes de incorporación de cambios. Por ejemplo, Bob puede generar mensajes de confirmación bien formateados y significativos. Examina el nombre de la rama y el historial de confirmaciones para que coincidan con las convenciones de estilo de un proyecto.

Bob también puede crear una solicitud de incorporación de cambios directamente desde el IDE de un desarrollador. Analiza el nombre de la rama, los cambios en el código y el historial de confirmaciones para entender el propósito y el alcance. A continuación, genera un título de PR y una descripción detallada que resume los cambios, detectando y utilizando automáticamente las plantillas de PR existentes en un proyecto para las descripciones de solicitud de incorporación de cambios.