Solicitudes de incorporación de cambios apiladas

A stack is a series of pull requests in the same repository where each pull request targets the branch of the pull request below it, forming an ordered chain that lands on a single branch, typically your main branch. Instead of one large pull request, you get a set of smaller pull requests. Since each pull request has its own focused diff, teammates can review and approve each layer independently.

Cada solicitud de incorporación de cambios de una pila se evalúa con respecto a las reglas de la base de la pila , normalmente main , independientemente de la rama que tenga como destino directamente. Esto significa que las solicitudes de incorporación de cambios de la pila media se mantienen en el mismo estándar que la solicitud de incorporación de cambios inferior.

Disponibilidad de solicitudes de incorporación de cambios apiladas

La gh stackGitHub CLI extensión controla el flujo de trabajo de desarrollo local. Crea y realiza un seguimiento de las ramas en el orden de dependencia correcto, mantiene las ramas rebasedas, inserta ramas, crea y vincula solicitudes de incorporación de cambios y navega entre capas.

GitHub CLI no es necesario. Las operaciones de Git subyacentes son estándar y, en su lugar, puede crear pilas desde el GitHub sitio web.

Si usa otras herramientas, como Jujutsu o Sapling, para administrar e insertar las ramas locales, puede seguir usando GitHub CLI o el GitHub sitio web para abrir una pila de solicitudes de incorporación de cambios de esas ramas. Consulte Uso de otras herramientas con solicitudes de incorporación de cambios apiladas.

Troncos para solicitudes de incorporación de cambios apiladas

El tronco de una pila es la rama base de la solicitud de incorporación de cambios inferior. Cada otra solicitud de incorporación de cambios de la pila se basa en ella. El tronco tiene como valor predeterminado la rama predeterminada del repositorio, como main, pero puede ser cualquier rama, como una rama de versión o una rama de características de larga duración.

Para establecer el tronco:

• Desde GitHub CLI pase la --base BRANCH opción al gh stack init comando (por ejemplo, gh stack init --base release auth-layer).
• Desde el GitHub sitio web , cree la solicitud de incorporación de cambios inferior en cualquier rama que desee como tronco. El resto de la pila se basa en él.

Las reglas de protección de rama, las comprobaciones necesarias y la CI se evalúan en cualquier tronco que tenga como destino la pila, no solo en la rama predeterminada.

Protecciones de rama y comprobaciones necesarias

Todos los siguientes se evalúan como si cada solicitud de incorporación de cambios tiene como destino la base de pila, no la rama directamente debajo de ella:

Regla	Cómo se evalúa
Revisiones requeridas	Se evalúa en la base de la pila.
Comprobaciones de estado requeridas	Se evalúa en la base de la pila.
CODEOWNERS	Se evalúa a partir de la base de la pila. Cambios en CODEOWNERS en una solicitud de incorporación de cambios inferior, pero no afecta a las solicitudes de incorporación de cambios por encima de ella.
Flujos de trabajo de análisis de código	Se evalúa en la base de la pila.

GitHub Actions

GitHub Los flujos de trabajo de acciones se desencadenan como si cada solicitud de incorporación de cambios de la pila tenga como destino la base de la pila. Un flujo de trabajo configurado para ejecutarse en pull_request eventos que tienen como destino main las ejecuciones para cada solicitud de incorporación de cambios en la pila, no solo la inferior, por lo que no se requieren cambios de flujo de trabajo.

Los metadatos de pila, como la rama base de la pila, están disponibles en expresiones de flujo de trabajo a través github.event.pull_request.stackde . Esta propiedad solo está presente cuando la solicitud de incorporación de cambios pertenece a una pila.

Para obtener el conjunto completo de campos y patrones de metadatos para reducir el uso de CI redundante, consulte Optimización de CI para solicitudes de incorporación de cambios apiladas.

Requisitos de fusión

Antes de que una solicitud de incorporación de cambios en una pila pueda combinarse, se deben cumplir todas las siguientes condiciones:

• La solicitud de incorporación de cambios cumple todos los requisitos de protección de rama para la base de la pila, incluidas las revisiones necesarias, las comprobaciones de estado necesarias y las aprobaciones CODEOWNER.
• Todas las solicitudes de incorporación de cambios debajo de ella en la pila también cumplen esos requisitos.
• La pila tiene un historial totalmente lineal entre sus ramas.

Por ejemplo, en la pila main ← PR1 ← PR2 ← PR3, combinar pr #3 requiere PR #1 y PR #2 para pasar también comprobaciones, tener revisiones necesarias y satisfacer todas las reglas de protección de rama.

Métodos de combinación

Las pilas admiten los tres métodos de combinación. En cada caso, las solicitudes de incorporación de cambios llegan como una única operación atómica:

• La confirmación de combinación crea una confirmación de combinación para todo el grupo de solicitudes de incorporación de cambios que se combina, conservando el historial de confirmaciones completo de cada solicitud de incorporación de cambios.
• Squash crea una confirmación limpia y aplastada por solicitud de incorporación de cambios. La combinación de n solicitudes de incorporación de cambios crea n confirmaciones aplastadas en la rama base.
• Rebase reproduce las confirmaciones de cada solicitud de incorporación de cambios en la rama base, creando un historial lineal sin confirmaciones de combinación.

Combinar a través de una cola de mezcla

Las pilas admiten totalmente las colas de mezcla. Todas las solicitudes de incorporación de cambios de la pila se agregan a la cola en el orden correcto. Si se quita o se expulsa una solicitud de incorporación de cambios de la cola, también se quitan todas las solicitudes de incorporación de cambios por encima de ella en la pila.

Historial lineal

Un historial totalmente lineal entre cada rama de la pila es un requisito estricto para la combinación. Una pila puede perder su historial lineal cuando los cambios se insertan en una rama inferior o cuando el tronco se mueve hacia delante.

Para restaurar un historial lineal, ejecute una base en cascada:

• Desde la CLI : ejecute gh stack rebasey, a continuación, inserte con gh stack push.
• En el GitHub sitio web , haga clic en Rebase stack (Rebase stack ) en el cuadro de combinación para desencadenar una rebase en cascada del lado servidor.

Para obtener instrucciones, consulte Administración de solicitudes de incorporación de cambios apiladas.

Lectura adicional

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