Una pila es una serie de solicitudes de incorporación de cambios en el mismo repositorio donde cada solicitud de incorporación de cambios tiene como destino la rama de la solicitud de incorporación de cambios debajo de ella, formando una cadena ordenada que llega a una sola rama, normalmente la rama principal. En lugar de una solicitud de incorporación de cambios grande, obtendrá un conjunto de solicitudes de incorporación de cambios más pequeñas. Dado que cada solicitud de incorporación de cambios tiene su propia diferencia centrada, los compañeros de equipo pueden revisar y aprobar cada capa de forma independiente.
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 a la que se dirige directamente. Esto significa que a las pull requests del medio se les exige el mismo nivel que a la pull request inferior.
Nota:
- Las solicitudes de incorporación de cambios apiladas requieren que todas las ramas estén en el mismo repositorio. No se admiten pilas de bifurcación cruzada.
- Las solicitudes de incorporación de cambios apiladas no se admiten en GitHub Desktop.
Disponibilidad de pull requests apiladas
La extensión gh stackGitHub CLI gestiona el flujo de trabajo de desarrollo local. Crea y realiza un seguimiento de las ramas en el orden de dependencia correcto, mantiene las ramas actualizadas mediante rebase, publica las 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 y enviar las ramas locales, puede seguir usando GitHub CLI o el sitio web GitHub para abrir una pila de solicitudes de incorporación de cambios de esas ramas. Consulte Usa otras herramientas con pull requests apiladas.
Ramas principales para pull requests apiladas
El trunk de una pila es la rama base de la pull request inferior. Todas las demás solicitudes de incorporación de cambios de la pila se basan en ella. La rama principal 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 la troncal:
- En GitHub CLI pase la opción
--base BRANCHal comandogh stack init, (por ejemplo,gh stack init --base release auth-layer). - Desde el GitHub sitio web, cree el pull request de abajo en cualquier rama que desee como rama principal. 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 rama principal a la que apunta la pila, no solo en la rama predeterminada.
Protección de ramas y comprobaciones obligatorias
Todo lo siguiente se evalúa como si cada pull request tuviera como destino la base de la pila, no la rama directamente debajo de ella:
| Regla | Cómo se evalúa |
|---|---|
| Revisiones requeridas | Se evalúa con respecto a la base de la pila. |
| Comprobaciones de estado requeridas | Se evalúa con respecto a la base de la pila. |
| CODEOWNERS | Se evalúa a partir de la base de la pila. Los cambios en CODEOWNERS en una solicitud de incorporación de cambios inferior, pero no afectan a las solicitudes de incorporación de cambios por encima de ella. |
| Flujos de trabajo de análisis de código | Se evalúa con respecto a 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 tuviera como destino la base de la pila. Un flujo de trabajo configurado para ejecutarse en eventos dirigidos a main se ejecuta para cada solicitud de incorporación de cambios en la pila, no solo la inferior, por lo que no se requieren cambios en el 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 de github.event.pull_request.stack. Esta propiedad solo está presente cuando la solicitud de extracción pertenece a un stack.
Para obtener el conjunto completo de campos y patrones de metadatos para reducir el uso de CI redundante, consulte Optimización de CI para pull requests en pila.
Rebasing
Cuando haya un rebase disponible o sea necesario, el cuadro de fusión lo indicará mostrando un botón Rebase stack. Por ejemplo, esto puede ocurrir cuando los cambios en una pull request hacen que la pila no sea lineal. Cuando se combina la pull request de abajo, se produce automáticamente un rebase y normalmente no es necesario hacer rebase manualmente.
Cuando se vuelve a basar un stack, puede esperar lo siguiente:
- El rebase de la serie genera commits firmados.
- Hacer rebase de una pila no cuenta como un commit nuevo y revisable si la diferencia no cambia. Las aprobaciones se conservan en esta situación, incluso cuando está habilitada la regla Descartar aprobaciones de solicitudes de extracción obsoletas cuando se envían nuevas confirmaciones.
Requisitos de fusión
Antes de que una pull request en una pila pueda fusionarse, se deben cumplir todas las siguientes condiciones:
- La pull request cumple todos los requisitos de protección de rama para la base de la rama apilada, incluidas las revisiones necesarias, las comprobaciones de estado necesarias y las aprobaciones de los propietarios del código.
- Todas las solicitudes de incorporación de cambios por debajo de esta 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.
Nota:
Las solicitudes de incorporación de cambios apiladas admiten la combinación con reglas de omisión/bypass, pero solo se puede combinar la solicitud de incorporación de cambios inferior de esta manera. No se puede fusionar toda la pila con reglas de bypass. Consulta Creación de conjuntos de reglas de un repositorio
Métodos de combinación
Las pilas admiten los tres métodos de combinación. En cada caso, las pull requests llegan como una única operación atómica:
- Confirmación de fusión crea una confirmación de fusión para cada solicitud de extracción que se combina, conservando el historial de confirmaciones completo de cada solicitud de extracción.
- Squash crea un commit limpio y combinado por solicitud de incorporación de cambios. La combinación de
npull requests creancommits combinados en la rama base. - Rebase reaplica los commits de cada pull request sobre la rama base, creando un historial lineal sin commits de fusión.
Combinar a través de una cola de fusión
Las pilas admiten totalmente las colas de fusión. Todos los pull requests del stack 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.
Nota:
Para mantener una pila junta, la cola de fusión permite que el grupo de fusión supere su tamaño máximo configurado hasta un 50 %. Si la pila es demasiado grande para ajustarse a ese búfer, se colocará automáticamente en el siguiente grupo de mezcla como una sola unidad.
Historia lineal
Un historial totalmente lineal entre cada rama de la pila es un requisito estricto para la fusión. Un stack puede perder su historial lineal cuando se hace push de cambios a una rama inferior o cuando la rama principal avanza.
Para restaurar un historial lineal, ejecute un rebase en cascada:
- Desde la CLI — ejecute
gh stack rebase, y, a continuación, haga push congh stack push. - En el GitHub sitio web, haga clic en Rebase stack en el cuadro de combinación para desencadenar una rebase en cascada del lado del servidor.
Para obtener instrucciones, consulte Administración de pull requests apiladas.