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

Planee e implemente solicitudes de incorporación de cambios apiladas en su organización, por lo que los equipos pueden enviar cambios grandes como capas pequeñas y revisables sin poner en peligro las reglas y comprobaciones existentes.

> \[!NOTE]
> Las solicitudes de incorporación de cambios apiladas están en versión preliminar pública y están sujetas a cambios.

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í, lo que facilita la revisión, la combinación y el envío de cada capa. Las solicitudes de incorporación de cambios apiladas proporcionan a los desarrolladores la flexibilidad de finalizar un trabajo y pasar directamente a la siguiente sin esperar a que las revisiones llegaran. Esto importa más cuando el trabajo depende naturalmente de lo que vino antes, que es común cuando un equipo trabaja en una versión grande y cada cambio se basa en el último.

Este tutorial le guía a través de la preparación de la organización para las solicitudes de incorporación de cambios apiladas: revisar las consideraciones de lanzamiento, comprender cómo funcionan las reglas de protección de ramas y la CI con pilas y empezar a trabajar con los equipos. 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](/es/pull-requests/get-started/about-stacked-prs).

## Prerequisites

Si el equipo ya usa solicitudes de incorporación de cambios, está configurado para usar solicitudes de incorporación de cambios apiladas. Todo lo demás de este tutorial es opcional, pero supone que su organización tiene:

* GitHub CLI, con la `gh-stack` extensión instalada. La extensión de la CLI es la manera más completa de crear y administrar pilas.
* Reglas de protección de rama configuradas para la rama predeterminada.
* GitHub Actions flujos de trabajo que se ejecutan en solicitudes de incorporación de cambios destinadas a la rama predeterminada.

Copilot no es necesario usar solicitudes de incorporación de cambios apiladas, pero se recomienda a los equipos que quieran apilar los cambios generados por la inteligencia artificial. Las solicitudes de incorporación de cambios apiladas también funcionan con otros agentes de codificación de IA, como Claude Code y Codex, mediante la aptitud de agente proporcionada. Consulte [Pila de código generado por IA en solicitudes de incorporación de cambios](/es/copilot/tutorials/stack-ai-generated-code-in-pull-requests).

## 1. Revisar las consideraciones de lanzamiento

Antes de introducir solicitudes de incorporación de cambios apiladas a los equipos, revise las siguientes consideraciones para que todos sepan qué esperar.

### Las pilas deben ser lineales y no pueden incluir bifurcaciones

Cada solicitud de incorporación de cambios de una pila debe formar parte del mismo repositorio y compilar en una sola cadena lineal de ramas. No se admiten pilas con estructuras de bifurcación o solicitudes de extracción de bifurcaciones. Si los equipos dependen de bifurcaciones para las contribuciones, planee mantener esas contribuciones fuera de las pilas por ahora.

### La reordenación de una pila requiere GitHub CLI

Si el equipo necesita reordenar las solicitudes de incorporación de cambios en una pila, deberá usarlas `gh stack modify` en la `gh stack`GitHub CLI extensión. No hay forma de reordenar una pila desde el GitHub sitio web. Los equipos que no usan la CLI localmente deben planear cuidadosamente el orden de la pila o instalar la extensión para esta tarea.

### No se puede extender una pila completada

Una vez que todas las solicitudes de incorporación de cambios de una pila se han combinado, esa pila se cierra. Si un equipo agrega nuevas ramas en la parte superior y se ejecuta `gh stack submit`, la CLI inicia una nueva pila con la misma rama base. Los equipos que quieran seguir trabajando en una pila deben planear mantener la pila abierta hasta que se complete todo el trabajo.

## 2. Comprender cómo funcionan las reglas de protección de ramas y ci con pilas

Las solicitudes de incorporación de cambios apiladas están diseñadas para aplicar las reglas existentes de la misma manera que cualquier otra solicitud de incorporación de cambios, pero merece la pena comprender cómo, dado que cada solicitud de incorporación de cambios de una pila se evalúa de forma un poco diferente de la que se espera.

Cada solicitud de incorporación de cambios en una pila, no solo la inferior, se evalúa con respecto a la **base de la pila** (normalmente `main`), en lugar de en la rama a la que se dirige directamente. Esto significa lo siguiente:

* 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.
* Flujo GitHub Actions de trabajo que se desencadena en `pull_request` eventos que tienen como destino `main` las ejecuciones 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.stack`de , 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 omitir trabajos costosos en ejecuciones redundantes 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](/es/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).

Opcionalmente, puede ver esto en acción abriendo una pequeña pila de pruebas en un repositorio con los conjuntos de reglas estándar y comprobaciones necesarias y confirmando que:

1. Las revisiones y las comprobaciones de estado son necesarias en todas las solicitudes de incorporación de cambios de la pila, no solo en la parte inferior.
2. Los flujos de trabajo de CI se ejecutan en cada solicitud de incorporación de cambios de la pila.
3. La combinación se bloquea hasta que la solicitud de incorporación de cambios en la pila que desea combinar y todo lo que se encuentra debajo de ella cumple sus requisitos.

Para obtener la lista completa de reglas y requisitos, consulte [Solicitudes de incorporación de cambios apiladas](/es/pull-requests/reference/stacked-pull-requests).

## 3. Introducción a los equipos

Una vez que haya revisado las consideraciones de lanzamiento y comprenda cómo funcionan las reglas y ci con las pilas, apunte a los equipos a [Solicitudes de incorporación de cambios 🥞 apiladas](/es/pull-requests/how-tos/stacked-pull-requests), que reúne todo lo que necesitan para empezar a crear, revisar y combinar solicitudes de incorporación de cambios apiladas.

## 4. Actualizar las herramientas de programación

A medida que su organización adopta solicitudes de incorporación de cambios apiladas, 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.

> \[!IMPORTANT]
> La combinación de una solicitud de incorporación de cambios apilada requiere stacks API. Los puntos de conexión de combinación de solicitudes de incorporación de cambios heredados no pueden combinar una pila. Si su organización combina solicitudes de incorporación de cambios mediante programación, por ejemplo, mediante herramientas internas o bots de ChatOps, actualice esas herramientas para llamar a stacks API antes de implementar solicitudes de incorporación de cambios apiladas.

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 [Solicitudes de incorporación de cambios apiladas en las API REST y GraphQL](/es/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis).
* **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.