Implementación de solicitudes de incorporación de cambios apiladas en su organización

Las solicitudes de incorporación de cambios apiladas permiten a los desarrolladores dividir grandes cambios en una cadena de solicitudes de incorporación de cambios pequeñas y centradas que se basan entre sí. Este enfoque puede ayudar a su organización a mantener la calidad de las revisiones a medida que los desarrolladores generan más código, incluidos con Copilot y otros agentes de codificación.

Las solicitudes de incorporación de cambios apiladas no requieren ninguna configuración ni habilitación. Si el equipo ya usa solicitudes de incorporación de cambios, puede crear una pila hoy mismo. Los pasos siguientes le ayudarán a preparar los controles existentes y a admitir un lanzamiento suave, no activar una característica.

Este tutorial le ayuda a decidir si las solicitudes de incorporación de cambios apiladas se ajustan a su organización, asegúrese de que las bases están en vigor, pilote el flujo de trabajo, admita la adopción y actualice las herramientas de programación. Para obtener una comprensión fundamental de las solicitudes de incorporación de cambios apiladas, consulte Acerca de las solicitudes de incorporación de cambios apiladas.

1. Decidir si las solicitudes de incorporación de cambios apiladas son las adecuadas

Use esta comprobación automática rápida antes de invertir en un lanzamiento:

• ¿Los equipos generan un gran volumen de código, ya sea con ellos mismos o con Copilot otros agentes de codificación?
• ¿Los equipos trabajan en características grandes, especialmente dentro de monorepos, que son difíciles de dividir en solicitudes de incorporación de cambios independientes?

Si se describen los equipos, las solicitudes de incorporación de cambios apiladas pueden ayudarles a enviar cambios dependientes en unidades más pequeñas sin esperar a que cada solicitud de incorporación de cambios se combine antes de iniciar la siguiente, siempre y cuando su trabajo se ajuste a una restricción: todas las solicitudes de incorporación de cambios de una pila deben estar en el mismo repositorio, siguiendo una sola cadena lineal de ramas. Las pilas no pueden incluir bifurcaciones ni estructuras de bifurcación, por lo que los equipos que dependen en gran medida de bifurcaciones para las contribuciones deben mantener esas contribuciones fuera de las pilas por ahora.

2. Asegúrese de que las bases están en su lugar

Cada solicitud de incorporación de cambios de una pila se evalúa con respecto a la base de la pila (normalmente main), en lugar de la rama que tiene como destino directamente. Las reglas de protección de ramas existentes o conjuntos de reglas y flujos de trabajo de CI se aplican automáticamente:

• Las revisiones necesarias, las comprobaciones de estado necesarias y CODEOWNERS se aplican a la rama base de la pila para cada solicitud de incorporación de cambios de la pila.
• Un GitHub Actions flujo de trabajo que se desencadena en pull_request eventos destinados a la rama predeterminada de un repositorio se ejecuta para cada solicitud de incorporación de cambios de la pila, por lo que la configuración de CI existente no necesita cambiar.
• Los metadatos de pila están disponibles en expresiones de flujo de trabajo a través github.event.pull_request.stackde , si desea personalizar el comportamiento del flujo de trabajo específicamente para las solicitudes de incorporación de cambios apiladas. Dado que un flujo de trabajo se ejecuta una vez por solicitud de incorporación de cambios en una pila, los equipos pueden usar estos metadatos para limitar trabajos costosos y reducir el uso de CI. Para obtener más información, consulte Optimización de CI para solicitudes de incorporación de cambios apiladas.

Una adición opcional que merece la pena tener en cuenta: si los desarrolladores necesitan reordenar las solicitudes de incorporación de cambios después de crear una pila sin interrumpirla, adopte la gh stack extensión para GitHub CLI. La reordenación local requiere gh stack modify; en el GitHub sitio web, los desarrolladores deben despilar las solicitudes de incorporación de cambios y volver a crear la pila en el orden deseado.

Una pila también se cierra automáticamente una vez que cada solicitud de incorporación de cambios en ella se ha combinado. Si un equipo agrega nuevas ramas encima de una pila combinada y ejecuta gh stack submit, la CLI inicia una nueva pila con la misma rama base. No extiende el original. Los equipos que quieran seguir trabajando en un conjunto de cambios deben planear mantener abierta la pila hasta que se complete todo el trabajo.

Para obtener la lista completa de reglas y requisitos, consulte Solicitudes de incorporación de cambios apiladas.

3. Piloto con un pequeño grupo

Elija un pequeño grupo de desarrolladores que generen un gran volumen de código, ya sea a través de o a través Copilot de otros agentes de codificación. Pida al grupo que use una característica real y representativa para el piloto en lugar de un ejemplo descartable.

Para crear su primera pila, dirija a los usuarios a Inicio rápido para solicitudes de incorporación de cambios apiladas. Después del piloto, recopile comentarios de los desarrolladores y revisores sobre:

• Cómo encaja el planeamiento de la pila en su flujo de trabajo existente y si los desarrolladores necesitan reordenar localmente, lo que requiere la gh stack extensión
• Si el flujo de revisión se sintió diferente ahora que cada solicitud de incorporación de cambios de la pila lleva sus propias revisiones y comprobaciones de estado necesarias
• Cualquier falta de soporte técnico o documentación en la que se encontraron

4. Implementación y apoyo de la adopción

Después del piloto, comparta instrucciones diarias sobre cómo crear, revisar, administrar y combinar pilas con equipos: Solicitudes de incorporación de cambios apiladas.

Como se indicó en el paso 2, se recomienda la gh stackGitHub CLI extensión cuando los desarrolladores necesiten reordenar una pila sin interrumpirla. Los equipos que no usan herramientas locales de la CLI pueden desmontar y volver a crear la pila en el orden deseado en el GitHub sitio web.

Los equipos que producen un gran volumen de código generado por ia, una de las señales de ajuste del paso 1, pueden encontrar instrucciones sobre el apilamiento de cambios de los agentes de codificación en Pila de código generado por IA en solicitudes de incorporación de cambios.

5. Actualizar las herramientas mediante programación

Para mantener la adopción, revise las herramientas, bots o paneles internos que creen, combinen o realicen un seguimiento de las solicitudes de incorporación de cambios mediante programación y actualícelas para tener en cuenta las pilas.

Si su organización proporciona una CLI interna u otras herramientas para desarrolladores, puede usar stacks API para integrar la creación y administración de la pila en esas herramientas existentes en lugar de exigir a los desarrolladores que adopten gh stack.

También puede realizar un seguimiento de la actividad de pila mediante programación, por ejemplo, entre paneles, bots o herramientas internas.

• API REST: cada solicitud de incorporación de cambios devuelta por la API incluye un stack objeto cuando pertenece a una pila, mostrando el número, el tamaño de la pila, la posición de la solicitud de incorporación de cambios dentro de ella y la rama base de la pila. Una API de stacks dedicada (GET /repos/{owner}/{repo}/stacks) también enumera todas las pilas de un repositorio o la pila específica que contiene una solicitud de incorporación de cambios determinada. Consulte API y webhooks de solicitudes de incorporación de cambios apiladas.
• Webhooks: la carga del pull_request webhook incluye el mismo stack objeto cada vez que una solicitud de incorporación de cambios pertenece a una pila. Una acción dedicada stacked se desencadena cuando se agrega por primera vez una solicitud de incorporación de cambios a una pila, por lo que puede reaccionar en el momento en que se forma una pila.

En ambos casos, el stack campo es null para las solicitudes de incorporación de cambios independientes, por lo que las integraciones existentes que no esperan que las pilas sigan funcionando sin cambios.