La extensión gh stack para GitHub CLI crea y gestiona pilas de pull requests a partir de tu repositorio local. Para obtener una introducción a las pilas, consulte Pull requests apiladas.
Installation
gh extension install github/gh-stack
La extensión requiere GitHub CLI (gh) versión 2.0 o posterior, y Git 2.36 o posterior.
Nota:
La gh stack extensión usa la GitHub CLI autenticación. Si aún no se ha autenticado, ejecute gh auth login.
Resumen de comandos
| Comando | Purpose |
|---|---|
gh stack init | Inicialice una nueva pila en el repositorio actual. |
gh stack add | Agregue una nueva rama en la parte superior de la pila actual. |
gh stack view | Ver la pila actual. |
gh stack checkout | Extrae una pila por número de pila, número de solicitud de extracción, URL de solicitud de extracción o nombre de rama. |
gh stack modify | Reestructurar la pila actual de forma interactiva. |
gh stack unstack | Elimina una pila del seguimiento local y desmontala en GitHub. |
gh stack submit | Realiza un push de todas las ramas y, a continuación, crea o actualiza las solicitudes de extracción y la pila en GitHub. |
gh stack sync | Obtenga, haga rebase, envíe y sincronice el estado de la solicitud de extracción en un solo comando. |
gh stack rebase | Realiza un pull desde el servidor remoto y ejecuta un rebase en cascada en toda la pila. |
gh stack push | Inserte las ramas activas de la pila actual en el remoto. |
gh stack link | Vincula solicitudes de extracción a una pila en GitHub sin seguimiento local. |
gh stack merge | Fusiona una o varias pull requests apiladas de una vez. |
gh stack switch | Cambie interactivamente a otra rama de la pila. |
gh stack up | Suba hacia la parte superior de la pila, alejándose del tronco. |
gh stack down | Desplázate hacia la parte inferior de la pila, hacia el tronco. |
gh stack top | Salta al inicio de la pila. |
gh stack bottom | Salta al final de la pila. |
gh stack trunk | Salta a la rama troncal. |
gh stack alias | Cree un alias de comando corto para que pueda escribir menos. |
gh stack feedback | Comparta comentarios sobre la gh stack extensión. |
Gestión de la pila
gh stack init
Inicialice una nueva pila en el repositorio actual.
gh stack init [flags] [branches...]
Inicializa una nueva pila localmente. En modo interactivo (sin argumentos), el comando solicita un nombre de rama y ofrece usar la rama actual como primera capa.
Al proporcionar nombres de rama explícitos, las ramas existentes se adoptan automáticamente y se crean las ramas que faltan. El tronco tiene como valor predeterminado la rama predeterminada del repositorio, a menos que la invalide con --base.
Se pueden adoptar ramas extraídas en otros árboles de trabajo. Si la rama final ya está extraída en otro lugar, init deja la extracción actual sin cambios e informa del worktree propietario en su lugar.
El comando habilita git rerere automáticamente, de modo que las resoluciones de conflictos se conserven de un rebase a otro.
| Flag | Description |
|---|---|
-b, --base <branch> | Rama trunk de la pila (por defecto, la rama predeterminada del repositorio) |
Ejemplos:
# Interactive — prompts for branch names
gh stack init
# Non-interactive — specify first branch upfront
gh stack init feature-auth
# Use a different trunk branch
gh stack init --base develop feature-auth
# Adopt or create multiple branches at once
gh stack init feature-auth feature-api feature-ui
gh stack add
Agregue una nueva rama en la parte superior de la pila actual.
gh stack add [flags] [branch]
En el caso de una pila existente, crea una nueva rama en head actual, la agrega a la parte superior de la pila y la extrae. Debe ejecutar este comando mientras se encuentra en la rama superior de una pila. Si no proporciona un nombre de rama, el comando solicita uno.
Si el nombre de rama que proporcione ya está extraído en otro árbol de trabajo, add adopta la rama existente sin cambiar ninguna de las copias de trabajo. Los atajos de confirmación y preparación -A, -u y -m son incompatibles con ese tipo de adopción, y el comando produce un error antes de almacenar provisionalmente nada o cambiar la pertenencia a la pila.
Al ejecutar el comando de forma interactiva desde una rama que no forma parte de una pila, add ofrece inicializar una nueva pila en su lugar. El nombre de rama que proporcione o el nombre generado automáticamente se convierte en la primera capa. Si no proporciona un nombre, se usan las indicaciones estándar init .
Opcionalmente, puedes preparar los cambios y crear una confirmación como parte del flujo de add. Cuando se proporciona -m sin un nombre de rama explícito, el nombre de la rama se genera automáticamente en formato de fecha y de slug, como 03-24-add_login.
| Flag | Description |
|---|---|
-A, --all | Preparar todos los cambios, incluidos los archivos no rastreados. Se requiere -m. |
-u, --update | Preparar cambios solo en los archivos rastreados. Se requiere -m. |
-m, --message <string> | Cree una confirmación con este mensaje antes de crear la rama. |
Nota:
-A y -u son mutuamente excluyentes.
Ejemplos:
# Create a branch by name
gh stack add api-routes
# Prompt for a branch name interactively
gh stack add
# Stage all changes, commit, and auto-generate the branch name
gh stack add -Am "Add login endpoint"
# Stage only tracked files, commit, and auto-generate the branch name
gh stack add -um "Fix auth bug"
# Commit already-staged changes and auto-generate the branch name
gh stack add -m "Add user model"
# Stage all changes, commit, and use an explicit branch name
gh stack add -Am "Add tests" test-layer
# Stage only tracked files, commit, and use an explicit branch name
gh stack add -um "Update docs" docs-layer
gh stack view
Ver la pila actual.
gh stack view [flags]
Muestra todas las ramas de la pila, su orden, los enlaces a las solicitudes de incorporación de cambios y la confirmación más reciente con una marca de tiempo relativa. De forma predeterminada, el comando abre una vista de pantalla completa en un terminal interactivo e imprime la salida estática en un terminal no interactivo. Las opciones --short y --json se imprimen directamente en la salida estándar en ambos entornos.
| Flag | Description |
|---|---|
-s, --short | Salida compacta de una línea por rama |
--json | Generar los datos de la pila en formato JSON |
Ejemplos:
gh stack view
gh stack view --short
gh stack view --json
gh stack view --short usa hipervínculos OSC 8 para los números de las solicitudes de extracción cuando el terminal los admite. De lo contrario, se muestra la dirección URL completa para copiar y pegar. Establezca GH_STACK_HYPERLINKS=1 o GH_STACK_HYPERLINKS=0 para invalidar la detección de terminales.
gh stack checkout
Consulta una pila por su número de pila, el número de una solicitud de incorporación de cambios, la URL de una solicitud de incorporación de cambios o el nombre de una rama.
gh stack checkout [<stack-number> | <pr-number> | <pr-url> | <branch>]
| Flag | Description |
|---|---|
--print-path | Imprima la ruta de acceso absoluta del árbol de trabajo de destino. Requiere un objetivo explícito y nunca solicita. |
Para un destino que se extrajo en otro árbol de trabajo, --print-path imprime la ruta de acceso de ese árbol de trabajo sin cambiar ninguna de las dos extracciones. Para un objetivo que no está checked out en ningún sitio, el comando hace checkout de la rama en el árbol de trabajo actual antes de imprimir su ruta de acceso. Sin la marca, intentar extraer un destino ocupado en otro lugar es un error que incluye un diagnóstico de ruta de acceso, en lugar de un cambio correcto. Consulte Navegación para obtener más información sobre el contrato de respuesta.
Un número sin más se interpreta en primer lugar como un número de pila o de solicitud de incorporación de cambios. Se trata de identificadores de ámbito de repositorio que se muestran en la GitHub interfaz de usuario. Si nada coincide con el número, se prueba como nombre de rama.
Al hacer referencia a una pila remota, el comando captura la pila en GitHub, extrae las ramas y configura la pila localmente. Si la pila ya existe localmente y coincide, el comando cambia a la rama. Si las pilas locales y remotas tienen composiciones diferentes, se te pedirá que resuelvas el conflicto.
Cuando indicas un nombre de rama, el comando comprueba primero las pilas de las que se lleva un seguimiento localmente. Si la rama no está siendo rastreada localmente, el comando busca la rama en stacks remotos y descarga el stack correspondiente. Si hay más de una pila que coincide, utiliza un número de pila o de solicitud de incorporación de cambios para elegir una de forma explícita.
Cuando ejecutas el comando sin argumentos en un terminal interactivo, primero comprueba si la rama actual pertenece a una pila del remoto de la que no se hace seguimiento local y te ofrece cambiarte a ella. Si no hay una coincidencia única, o rechazas la opción, se abre un selector con búsqueda que muestra todas las pilas que tienes disponibles, tanto las pilas de las que se hace seguimiento local como las pilas que solo existen en GitHub. Cada fila muestra el número de pila, su rama inferior y superior, la rama base, una barra de estado que resume cuántas de sus solicitudes de incorporación de cambios están fusionadas, abiertas, cerradas o aún no enviadas, y si la pila está disponible localmente o solo en el servidor remoto. Filtre con las pestañas Todos, Locales y Remotos , o escriba / para buscar. Se omiten las pilas totalmente combinadas. Al seleccionar una stack solo disponible en remoto, se clona en local antes de cambiar a esta.
Ejemplos:
# Check out a stack by its stack number
gh stack checkout 7
# Check out a stack by pull request number
gh stack checkout 42
# Check out a stack by pull request URL
gh stack checkout https://github.com/owner/repo/pull/42
# Check out a stack by branch name
gh stack checkout feature-auth
# Interactive — pick from all available stacks (local and remote)
gh stack checkout
gh stack modify
Reestructurar la pila actual de forma interactiva.
gh stack modify [flags]
Abre una interfaz de usuario interactiva de terminal para reestructurar una pila. Todos los cambios se almacenan provisionalmente en la interfaz y se aplican juntos al presionar Ctrl+S. No se pueden modificar las ramas de las solicitudes de incorporación de cambios combinadas.
| Flag | Description |
|---|---|
--continue | Continuar después de resolver conflictos |
--abort | Anule la sesión de modificación y restaure la pila en su estado antes de ejecutar el comando. |
Condiciones previas
El comando comprueba estas condiciones antes de abrir la interfaz:
- Debes tener una pila activa descargada localmente.
- El árbol de trabajo debe estar limpio, sin cambios no confirmados.
- No hay ninguna operación de rebase en curso.
- No hay ninguna pull request de la pila en cola para su fusión.
- El historial de commits debe ser lineal, sin commits de fusión ni ramas divergentes.
- Todos los árboles de trabajo necesarios para las acciones en el área de preparación y las ramas que sobreviven a la cascada deben estar limpios y libres de otras operaciones de Git.
Las ramas de pila se pueden distribuir entre los árboles de trabajo. Los cambios de nombre se realizan en el propio árbol de trabajo de la rama. Los cherry-picks de fold-down se ejecutan en el árbol de trabajo de la rama receptora. Las rebasificaciones en cascada ejecutan cada rama en su propio directorio de trabajo. Una rama que no está extraída en ningún lugar usa el árbol de trabajo desde el que se ejecutó modify, y las ramas insertas se crean como referencias sin nuevos árboles de trabajo. Se conservan las ramas quitadas y contraídas, y sus árboles de trabajo. La rama principal solo se lee, por lo que no es necesario que los árboles de trabajo de origen no relacionados o sin modificar estén limpios.
Operations
| Funcionamiento | Key | Effect |
|---|---|---|
| Drop | ||
| x | Elimina la rama y sus confirmaciones de la pila. Se conservan la rama local y la solicitud de incorporación de cambios asociadas. | |
| Pliegue hacia abajo | ||
| d | Incorpora las confirmaciones a la rama inferior, hacia el tronco. La rama plegada se elimina de la pila. | |
| Plegar hacia arriba | ||
| u | Incorpora las confirmaciones a la rama superior, alejándolas del tronco. La rama plegada se elimina de la pila. | |
| Insertar a continuación | ||
| i | Inserte una nueva rama vacía debajo del cursor, hacia el tronco. | |
| Insertar arriba | ||
| Yo | Inserte una nueva rama vacía encima del cursor, lejos del tronco. | |
| Bajar | ||
| Mayús+↓ | Reordene la rama hacia abajo, hacia el tronco. | |
| Subir | ||
| Mayús+↑ | Reordene la rama hacia arriba, lejos del tronco. | |
| Rename | ||
| r | Cambia el nombre de la rama mediante un indicador en línea. | |
| Undo | ||
| z | Deshacer la última acción preconfigurada. |
Fase de aplicación
Al presionar Ctrl+S, los cambios preparados se aplican cambiando el nombre de las ramas, insertando ramas nuevas, plegando o eliminando ramas y ejecutando un rebase en cascada para crear un historial lineal de confirmaciones con el estado de la pila que quieras.
Si se produce un conflicto de rebase, puede:
- Resuelva los conflictos, almacene provisionalmente los archivos y, a continuación, ejecute
gh stack modify --continue. - Ejecute
gh stack modify --abortpara anular la operación y restaurar la pila en su estado anterior.
Resuelva y prepare los conflictos en el directorio de trabajo indicado en el mensaje de conflicto, que puede ser un directorio de trabajo del receptor de fold externo o un directorio de trabajo del propietario de rebase en lugar de aquel desde el que ejecutó modify. Tanto --continue como --abort se pueden ejecutar desde cualquier árbol de trabajo vinculado, ya que usan el propietario registrado en lugar del checkout actual. Continuar reanuda las acciones estructurales restantes, así como las reubicaciones de base restantes. Al anular, se revierten los cambios de nombre en sus propios árboles de trabajo, solo se restauran las referencias tocadas por la operación y solo se eliminan las referencias que creó. Si se produce un error en la restauración o en un guardado de diario o de catálogo, se conserva el estado de recuperación para que pueda volver a intentarlo.
Otros árboles de trabajo nunca se cambian a una rama diferente. El árbol de trabajo desde el que se ejecutó modify vuelve a su rama original, incluido su nuevo nombre si se ha cambiado el nombre de esa rama, o a la rama superviviente más cercana si la rama original ha desaparecido. Si esa rama superviviente está extraída en otro lugar, el árbol de trabajo mantiene su rama original conservada y el comando informa de la ruta de acceso de la rama superviviente. Cualquier estado pendiente usado por gh stack submit solo se consume para la pila que se acaba de modificar.
Después de modificar
Si ya has creado una pila de solicitudes de extracción en GitHub, ejecuta gh stack submit para enviar las ramas actualizadas y volver a crear la pila. El stack anterior se reemplaza automáticamente.
Ejemplos:
# Open the interactive modify interface
gh stack modify
# Continue after resolving a conflict
gh stack modify --continue
# Abort and restore to the previous state
gh stack modify --abort
gh stack unstack
Elimina una pila del seguimiento local y desmontala en GitHub. Este comando también está disponible como gh stack delete.
gh stack unstack [<stack-number>] [flags]
Sin argumentos, el comando se dirige a la pila activa, que es la pila que contiene la rama actualmente seleccionada. Desapila la pila de GitHub y elimina el seguimiento local.
Introduce un número de pila, el identificador que aparece en la interfaz de usuario de la pila en GitHub, para desmontar una pila específica. Esto funciona desde cualquier lugar del repositorio, independientemente de si la pila está descargada localmente o no, ya que la pila se desmonta directamente a través de la API de GitHub. Cuando la pila también está disponible localmente, se elimina también su seguimiento local.
Las pull requests fusionadas, en proceso de fusión o en cola para fusionarse no se pueden eliminar de una pila en GitHub y siguen formando parte de la pila. Cuando se eliminan todas las solicitudes de incorporación de cambios, la pila se disuelve y se elimina cualquier seguimiento local. Cuando algunas solicitudes de incorporación de cambios permanecen apiladas, la pila se mantiene y el seguimiento local, si existe, no se modifica. Use --local para omitir la operación remota y quitar solo el seguimiento local.
Este comando es útil cuando necesita reestructurar una pila quitando una rama, insertando una rama, reordenando ramas, cambiando el nombre de las ramas o realizando otros cambios grandes. Después de desmontar, use gh stack init para volver a crear la pila con la estructura que desee. Las ramas existentes se incorporan automáticamente.
| Flag | Description |
|---|---|
--local | Eliminar solo la pila localmente, manteniéndola en GitHub |
Ejemplos:
# Unstack the current stack on GitHub and remove local tracking
gh stack unstack
# Unstack a specific stack by its number
gh stack unstack 7
# Only remove local tracking
gh stack unstack --local
Operaciones remotas
gh stack submit
Realiza un push de todas las ramas y, a continuación, crea o actualiza las solicitudes de extracción y la pila en GitHub.
gh stack submit [flags]
Crea una solicitud de incorporación de cambios para cada rama de la pila, enviando las ramas al repositorio remoto. Después de crear solicitudes de incorporación de cambios, submit crea automáticamente una pila en GitHub para vincular las solicitudes de incorporación de cambios. Si la pila ya existe en GitHub, por ejemplo de un envío anterior, las nuevas pull requests se añaden a la pila existente.
Si todas las solicitudes de incorporación de cambios de la pila ya se han fusionado, dicha pila se considera completa y no se puede ampliar. En ese caso, submit inicia automáticamente una nueva pila con base en el tronco para tus ramas sin fusionar y la crea en GitHub, dejando intacta la pila ya fusionada.
En un terminal interactivo, submit abre un editor de pantalla completa en una sola pantalla.
- Panel izquierdo. Todas las ramas sin una pull request se incluyen de forma predeterminada. Deseleccione los que no quiera enviar con Ctrl+X. Dado que cada solicitud de incorporación de cambios se basa en la rama que tiene debajo, al deseleccionar una rama también se deseleccionan las que están por encima de ella, y al volver a incluir una rama se vuelven a incluir las que están por debajo y de las que depende. Las ramas que ya tienen una pull request, ya esté abierta, en borrador, en cola o fusionada, se muestran como referencia, pero están bloqueadas. Edítalas en la web.
- Panel derecho. Para la rama seleccionada, redacta el título y la descripción, y elige si la solicitud de incorporación de cambios se abre lista para su revisión o como borrador. La descripción se rellena automáticamente a partir de la plantilla de solicitudes de incorporación de cambios de tu repositorio o de las confirmaciones, con una vista previa en Markdown. Para editar la descripción en un editor externo, presione Ctrl+E. La extensión utiliza el primer valor no vacío de las variables de entorno
GH_EDITOR,VISUALyEDITOR, en ese orden. Si no se ha configurado ninguno, se usavisi está disponible en tuPATH. Al seleccionar una rama bloqueada, se muestra una tarjeta de solo lectura con un enlace a su solicitud de extracción. Presione o para abrirlo en el explorador.
Presione Ctrl+S para enviar todas las solicitudes de incorporación de cambios incluidas a la vez. El editor admite la entrada de teclado y mouse. Pase --autoo ejecute el comando en un terminal no interactivo, como CI, para omitir el editor y usar títulos generados automáticamente.
Si las ramas ya tienen solicitudes de incorporación de cambios abiertas, pero no hay ninguna pila en GitHub, puede vincular las solicitudes de incorporación de cambios a una pila con Ctrl+B.
En el editor, las nuevas solicitudes de incorporación de cambios aparecen por defecto como listas para su revisión. Puede cambiar cualquier solicitud de extracción a borrador con el conmutador. Con --auto, los pull requests se crean en modo borrador, a menos que se pase --open.
| Flag | Description |
|---|---|
--auto | Omitir el editor y usar títulos de solicitud de incorporación de cambios generados automáticamente |
--open | Cree nuevas solicitudes de incorporación de cambios como listas para su revisión en lugar de borradores y marque las solicitudes de incorporación de cambios existentes como listas para su revisión. |
--remote <name> | Remoto al que hacer push (por defecto, el remoto detectado automáticamente) |
Ejemplos:
gh stack submit
gh stack submit --auto
gh stack submit --open
gh stack sync
Obtenga, haga rebase, envíe y sincronice el estado de la solicitud de extracción en un solo comando.
gh stack sync [flags]
Sincroniza toda la pila.
- Recuperar. Captura los cambios más recientes de
origin. - Reconciliar la pila remota. Duplica la pila de GitHub en tu equipo local. Cuando se han añadido solicitudes de extracción a la pila de GitHub, de modo que la pila remota va por delante de tu pila local, sus ramas se descargan y se añaden a tu pila local automáticamente. Cuando las pilas local y remota han divergido realmente, por ejemplo, porque has añadido una rama localmente mientras se añadían distintos pull requests a la pila de GitHub, se te pedirá que resuelvas la diferencia. Consulte Pilas divergentes. En un terminal no interactivo, una divergencia interrumpe la sincronización y no se envía ni se actualiza nada.
- Avanzar rápidamente el tronco. Avanza rápidamente la rama del tronco para que coincida con el remoto. Este paso se omite si las ramas se han divergido.
- Rebase en cascada. Rebasa todas las ramas de la pila sobre sus padres actualizados, pero solo si el tronco se ha movido. Si se detecta un conflicto, todas las ramas se restauran a su estado original y se recomienda ejecutar
gh stack rebasepara resolver los conflictos de forma interactiva. - Presionar. Envía todas las ramas usando
--force-with-leasesi se realizó un rebase. - Sincronizar solicitudes de incorporación de cambios. Sincroniza el estado de la solicitud de incorporación de cambios de GitHub e informa del estado de cada solicitud de incorporación de cambios.
- Sincroniza la pila. Vincula las solicitudes de incorporación de cambios abiertas de la pila a una pila en GitHub, creando el objeto de pila remota si aún no existe, o actualizándolo si está parcialmente formado. Esto solo sucede cuando existen dos o más solicitudes de incorporación de cambios. La sincronización nunca abre solicitudes de incorporación de cambios. Úselo
gh stack submitpara eso. - Poda. En terminales interactivas, te pide que elimines las ramas locales correspondientes a las solicitudes de incorporación de cambios fusionadas. Usa
--prunepara depurar automáticamente.
Una actualización remota limpia en la que las solicitudes de extracción se añaden sobre la pila local se descarga automáticamente sin pedir confirmación, por lo que sync se puede ejecutar de forma segura en automatizaciones. La sincronización solo solicita confirmación cuando las pilas han divergido realmente.
Pilas divergidas
Cuando ninguna pila es un prefijo exacto de la otra, por ejemplo, porque has añadido una rama localmente al mismo tiempo que se han añadido solicitudes de extracción independientes a la misma pila en GitHub, la sincronización no puede fusionarlas automáticamente. En un terminal interactivo, ofrece tres opciones.
- Utiliza la pila remota como fuente de referencia. Reemplaza la composición de la pila local por el control remoto y extrae las ramas que faltan. Si te encontrabas en una rama que ya no está presente en la pila remota, se te trasladará a la rama activa más cercana. Esto requiere un estado de trabajo limpio, sin cambios sin confirmar.
- Elimine la pila en GitHub. Elimina el objeto de pila en GitHub y detiene la sincronización. Tus solicitudes de incorporación de cambios y ramas locales permanecen intactas, y solo se elimina la pila de GitHub. Vuelva a crear la pila con
gh stack submit, ejecutandogh stack modifyprimero si desea cambiar su estructura. Esta es la forma de hacer que GitHub coincida con tu pila local, ya quesubmit, a diferencia desync, también crea solicitudes de incorporación de cambios para cualquier rama que aún no hayas enviado. - Cancelar. Anula la sincronización sin insertar ramas ni actualizar las solicitudes de incorporación de cambios.
En un terminal no interactivo, una divergencia anula la sincronización, saliendo correctamente, sin insertar ramas ni actualizar solicitudes de incorporación de cambios. Resuélvelo desapilando y recreando la pila.
| Flag | Description |
|---|---|
--remote <name> | Repositorio remoto desde el que obtener y al que enviar (por defecto, el remoto detectado automáticamente) |
--prune | Eliminar ramas locales de las solicitudes de extracción fusionadas |
Ejemplos:
gh stack sync
# Sync and automatically prune merged branches
gh stack sync --prune
gh stack rebase
Realiza un pull desde el servidor remoto y ejecuta un rebase en cascada en toda la pila.
gh stack rebase [flags] [branch]
Recoge los últimos cambios de origin y, a continuación, se asegura de que cada rama de la pila tenga la punta de la capa anterior en su historial de confirmaciones. Las ramas se rebasan en orden, desde el tronco hacia arriba.
Si se ha fusionado la solicitud de incorporación de cambios de una rama, el rebase cambia automáticamente al modo --onto para reproducir correctamente las confirmaciones sobre el destino de la fusión.
Si se produce un conflicto de rebase, la operación pausa e imprime los archivos en conflicto con números de línea. Resuelva los conflictos, preconfigurarlos con git addy, a continuación, continúe con --continue. Para deshacer completamente el rebase, usa --abort para restaurar todas las ramas al estado en que se encontraban antes del rebase.
| Flag | Description |
|---|---|
--downstack | Rebasar solo las ramas desde el tronco hasta la rama actual |
--upstack | Rebasar solo las ramas desde la rama actual hasta la parte superior |
--no-trunk | Omitir el tronco. Solo se bifurca la pila de rebase entre sí, sin captura ni base de tronco. |
--continue | Continuar con el rebase después de resolver los conflictos |
--abort | Anule la base de datos y restaure todas las ramas en su estado antes de la rebase. |
--remote <name> | Remoto desde el que realizar la recuperación (por defecto, el remoto detectado automáticamente) |
--committer-date-is-author-date | Establecer la fecha de confirmación como la fecha de autor durante el rebase. Alias: --preserve-dates. |
Los rebases que conservan la fecha usan explícitamente el back-end de combinación de Git, por lo que la configuración se mantiene incluso si hay conflictos.
--continue reutiliza la configuración nativa de rebase que se guardó cuando se inició el rebase y no vuelve a enviar las opciones de fecha solo de inicio.
| Argumento | Description |
|---|---|
[branch] | Rama de destino (por defecto es la rama actual) |
Ejemplos:
# Rebase the entire stack
gh stack rebase
# Only rebase branches below the current one
gh stack rebase --downstack
# Only rebase branches above the current one
gh stack rebase --upstack
# Rebase stack branches without pulling from or rebasing with trunk
gh stack rebase --no-trunk
# After resolving a conflict
gh stack rebase --continue
# Abort rebase and restore everything
gh stack rebase --abort
# Rebase and preserve committer date as author date
gh stack rebase --committer-date-is-author-date
gh stack push
Inserte las ramas activas de la pila actual en el remoto.
gh stack push [flags]
Envía todas las ramas activas, excluyendo las fusionadas y las en cola, en un único git push, utilizando una comprobación explícita por rama --force-with-lease. La actualización no es atómica. Las ramas cuyos contratos de alquiler caduquen pueden actualizarse incluso si se rechaza otra rama. Corrija la rama rechazada y vuelva a ejecutar el comando. Las ramas que ya se actualizaron permanecen sin cambios. Este comando no crea ni actualiza pull requests. Úselo gh stack submit para eso.
| Flag | Description |
|---|---|
--remote <name> | Remoto al que hacer push (por defecto, el remoto detectado automáticamente) |
Ejemplos:
gh stack push
gh stack push --remote upstream
gh stack link
Vincula solicitudes de extracción a una pila en GitHub sin seguimiento local.
gh stack link [flags] <stack-number | branch-or-pr> <branch-or-pr> [...]
Crea o actualiza una pila en GitHub a partir de nombres de ramas o números de solicitudes de incorporación de cambios y URL. Este comando no crea ni modifica ningún estado de seguimiento local. Está diseñado para usuarios que gestionan ramas localmente con otras herramientas, como Jujutsu, Sapling o git-town, y quieren abrir una serie de pull requests. Consulte Usa otras herramientas con pull requests apiladas.
Proporcione argumentos en orden de pila, de abajo a arriba. Los argumentos de las ramas se envían al remoto automáticamente antes de que se creen o se busquen las solicitudes de incorporación de cambios. En el caso de las ramas que ya tienen solicitudes de incorporación de cambios abiertas, se utilizan dichas solicitudes. Para las ramas sin solicitudes de extracción, se crean automáticamente nuevas solicitudes de extracción con el encadenamiento correcto de ramas base. Las solicitudes de extracción existentes cuya rama base no coincide con la cadena esperada se corrigen automáticamente.
Si las solicitudes de incorporación de cambios aún no están en una pila, se crea una nueva pila. Si algunas de las solicitudes de incorporación de cambios ya están en una pila, la pila existente se actualiza para incluir las nuevas solicitudes de incorporación de cambios. Las solicitudes de incorporación de cambios existentes nunca se eliminan de una pila, ya que la actualización es únicamente aditiva.
Para ampliar una pila existente sin volver a enumerar sus solicitudes de extracción, pase como primer argumento un número de pila, el número que se muestra en la interfaz de usuario de la pila en GitHub. Los argumentos restantes se anexan a la parte superior de esa pila. Los argumentos que ya están en la pila se omiten y se rechazan los argumentos que pertenecen a una pila diferente. Dado que los números de las pilas y de las solicitudes de extracción nunca se superponen, un primer argumento numérico se interpreta como una pila solo cuando coincide con una pila existente. De lo contrario, se trata como una pull request o una rama.
| Flag | Description |
|---|---|
--base <branch> | Rama base en la parte inferior de la pila (por defecto, es la rama predeterminada del repositorio). Esta marca se omite cuando se agrega a una pila existente. |
--open | Marcar las solicitudes de incorporación de cambios nuevas y existentes como listas para su revisión |
--remote <name> | Remoto al que hacer push (por defecto, el remoto detectado automáticamente) |
Ejemplos:
# Link branches into a stack (pushes, creates pull requests, creates stack)
gh stack link feature-auth feature-api feature-ui
# Link existing pull requests by number
gh stack link 10 20 30
# Link existing pull requests by URL
gh stack link https://github.com/owner/repo/pull/10 https://github.com/owner/repo/pull/20
# Add branches to an existing stack of pull requests
gh stack link 42 43 feature-auth feature-ui
# Append to the top of an existing stack by its stack number, with no need
# to list the pull requests already in stack 7 again
gh stack link 7 48 feature-ui
# Use a different base branch and mark pull requests as ready for review
gh stack link --base develop --open feat-a feat-b feat-c
gh stack merge
Fusiona una o varias pull requests apiladas de una vez.
gh stack merge [<stack-number> | <pr-number>]
Combina todas las solicitudes de extracción de la pila, hasta la solicitud de extracción que elijas incluida, en la rama base. La fusión es una sola operación de todo o nada. Si alguna solicitud de extracción no se puede fusionar, no se fusiona ninguna.
Si no se especifica ningún argumento, el comando usa la pila local activa. Indique un número de stack para fusionar un stack que no tiene en su copia local, lo que constituye una operación completamente remota, o indique un número de pull request para fusionar directamente hasta ese pull request.
En un terminal interactivo, el comando le pide que elija qué solicitudes de extracción fusionar, elija el método de fusión y confirme. En un terminal no interactivo, o cuando se utiliza --yes, toda la pila —o todo lo que hay hasta la solicitud de incorporación de cambios que se especifique— se fusiona sin solicitar confirmación, utilizando el método de fusión utilizado por última vez, a menos que se especifique otro.
Antes de la fusión, solo se comprueba el estado básico de la solicitud de incorporación de cambios. Cada solicitud de incorporación de cambios debe estar abierta y no debe ser un borrador. GitHub evalúa las reglas de protección de ramas y las reglas del repositorio cuando se ejecuta la fusión, y se te notifica cualquier fallo.
Nota:
No se pueden eludir los requisitos de fusión al fusionar solicitudes de incorporación de cambios apiladas.
Si la rama base usa una cola de mezcla, la pila se agrega a la cola en lugar de combinarse directamente. La cola elige el método de fusión, por lo que la solicitud omite el paso del método de fusión, y los indicadores --merge-method, --squash, --rebase y --merge se ignoran con una advertencia. Las solicitudes de incorporación de cambios que seleccione se agregan juntas a la cola, pero se fusionan a medida que la cola las procesa, por lo que pueden fusionarse en grupos distintos en lugar de fusionarse todas a la vez.
| Flag | Description |
|---|---|
--merge-method <method> | Método de combinación que se va a usar: merge, squasho rebase |
--merge, , --squash, --rebase | Abreviaturas del método de combinación correspondiente |
-y, --yes | Combinar sin solicitar confirmación |
Ejemplos:
# Merge the current stack, choosing pull requests interactively
gh stack merge
# Merge a stack you do not have checked out, by stack number
gh stack merge 7
# Merge everything up to and including pull request 42
gh stack merge 42
# Merge the whole current stack without prompting, squashing commits
gh stack merge --yes --squash
Navegación
Los comandos de navegación te permiten moverte entre ramas del stack actual sin tener que recordar los nombres de las ramas. La parte inferior de la pila es la rama más cercana al tronco, y la superior es la rama más alejada de este.
up se aleja del tronco y down se mueve hacia él.
Todos los comandos de navegación se limitan a los límites de la pila. Moverse hacia arriba desde la parte superior, o hacia abajo desde la parte inferior, no hace nada y muestra un mensaje.
up, down, top, bottom, trunky checkout con un destino explícito, todos admiten --print-path. Para un objetivo extraído en otro worktree, el comando imprime la ruta de acceso de ese worktree sin cambiar a él. Para un destino que no está extraído en ningún sitio, el comando lo extrae en el árbol de trabajo desde el que lo ejecutó y, a continuación, imprime la ruta de acceso de ese árbol de trabajo. Si el destino ya está extraído en el árbol de trabajo actual, el comando imprime la raíz del árbol de trabajo actual.
Cuando se usa --print-path con éxito, la salida estándar contiene solo la ruta de acceso absoluta sin procesar seguida de una sola línea nueva. Los diagnósticos se escriben en la salida de error estándar, y un objetivo fallido o ambiguo no genera ninguna salida estándar en absoluto; --print-path nunca solicita entrada. Sin la marca, al navegar a una rama que está extraída en otro lugar, se produce un error y se notifica la ruta de acceso de esa rama. Si envuelve gh stack en una función de shell para cd en la ruta de acceso impresa, compruebe primero el estado de salida del comando, ponga la ruta de acceso entre comillas y evite eval.
gh stack switch
Cambie interactivamente a otra rama de la pila.
gh stack switch
Muestra un selector interactivo que muestra todas las ramas de la pila actual, ordenadas desde arriba, más alejadas del tronco, hasta la parte inferior, más cercanas al tronco, con su número de posición. Selecciona una rama para pasar a ella.
Este comando requiere un terminal interactivo.
Ejemplos:
gh stack switch
# → Select a branch in the stack to switch to
# 5. frontend
# 4. api-endpoints
# 3. auth-layer
# 2. db-schema
# 1. config-setup
gh stack up
Suba hacia la parte superior de la pila, alejándose del tronco.
gh stack up [n]
Sube n ramas, con un valor predeterminado de 1. Si está en la rama del tronco, up se mueve a la primera rama de pila.
Ejemplos:
# Move up one layer
gh stack up
# Move up three layers
gh stack up 3
gh stack down
Desplázate hacia la parte inferior de la pila, hacia el tronco.
gh stack down [n]
Desplaza hacia abajo n ramas, con un valor predeterminado de 1.
Ejemplos:
# Move down one layer
gh stack down
# Move down two layers
gh stack down 2
gh stack top
Salta al inicio de la pila.
gh stack top
Echa un vistazo a la rama más alejada del tronco.
gh stack bottom
Salta al final de la pila.
gh stack bottom
Echa un vistazo a la rama más cercana al tronco.
gh stack trunk
Salta a la rama troncal.
gh stack trunk
Comprueba la rama de tronco de la pila actual, como main. Debe estar en una rama que forme parte de una pila.
Utilities
gh stack alias
Cree un alias de comando corto para que pueda escribir menos.
gh stack alias [flags] [name]
Instala un script contenedor pequeño en ~/.local/bin/ que reenvía todos los argumentos a gh stack. El nombre de alias predeterminado es gs, pero puede elegir cualquier nombre pasándolo como argumento. Después de la instalación, puede ejecutar gs push en lugar de gh stack push.
En Windows, no se admite la creación automática de alias. El comando imprime instrucciones manuales para crear un archivo por lotes o una función de PowerShell.
| Flag | Description |
|---|---|
--remove | Eliminación de un alias que creó anteriormente |
Ejemplos:
# Create the default alias (gs), so that "gs push" and "gs view" both work
gh stack alias
# Create a custom alias
gh stack alias gst
# Remove an alias
gh stack alias --remove
gh stack alias --remove gst
gh stack feedback
Comparta comentarios sobre la gh stack extensión.
gh stack feedback [title]
Abre una discusión en el repositorio gh-stack para que pueda enviar comentarios. Opcionalmente, puede proporcionar un título para la publicación de discusión.
Ejemplos:
gh stack feedback
gh stack feedback "Support for reordering branches"
Compatibilidad con worktree
gh stack funciona en los árboles de trabajo vinculados de Git en el mismo clon.
Todos los worktrees vinculados comparten un gh-stack directorio de estado y un diario de recuperación, almacenados en el directorio común del repositorio. El estado nativo de Git, como HEAD, el índice y los marcadores de rebase en curso o de cherry-pick, permanece local en cada worktree. Los comandos de mutación se serializan en todo el clon, pero los comandos de solo lectura, como gh stack view , por ejemplo, permanecen disponibles mientras una mutación se ejecuta en otro árbol de trabajo.
Los catálogos heredados sin conflictos se migran al formato actual automáticamente y se conservan los archivos originales. Los catálogos con definiciones en conflicto requieren conciliación manual. Complete cualquier recuperación heredada en curso en su árbol de trabajo original antes de migrar y no combine versiones de catálogo antiguas y nuevas en el mismo clon.
gh stack rebase y gh stack sync actualizan automáticamente las ramas de cualquier árbol de trabajo afectado que esté limpio, lo que significa que no tiene cambios pendientes de confirmación, ninguna otra operación de Git en curso y que, por lo demás, no haya cambiado. Bloquean las actualizaciones de los árboles de trabajo que están sucios, ocupados, ausentes o han cambiado inesperadamente. Ninguno de los comandos guarda tus cambios en el stash automáticamente ni crea o quita los worktrees por ti.
Para los comandos que comparten un diario de recuperación, --continue y --abort operan en el árbol de trabajo registrado en el diario, no en el árbol de trabajo desde el que se ejecuta el comando. Si la recuperación falla a mitad del proceso, se conserva el estado de la operación para que pueda volver a intentarlo.
En el caso de los repositorios creados con git init --separate-git-dir, gh stack admite la invocación desde el árbol de trabajo principal y desde los árboles de trabajo vinculados que tienen un enlace de retorno core.worktree absoluto o relativo al árbol de trabajo principal, incluida la configuración almacenada en el archivo config.worktree del árbol de trabajo principal. La única configuración no admitida se da al invocar gh stack desde un árbol de trabajo vinculado que no tiene ningún vínculo hacia atrás al árbol de trabajo principal. Si una operación requiere acceso a ese worktree y no puede encontrarlo, la operación falla con instrucciones sobre cómo proceder; los worktrees que no se ven afectados por el backlink que falta continúan funcionando normalmente.
gh stack nunca usa un directorio de administración de Git como destino de extracción.
Variables de entorno
| Variable | Valores | Description |
|---|---|---|
GH_STACK_THEME | ||
auto (predeterminado), light, dark | Controla la paleta de colores de las pantallas interactivas para submit, modify y view, y toda la salida de comandos en color. Los colores se adaptan automáticamente al fondo del terminal. Establezca esta variable para forzar la paleta clara u oscura cuando un terminal no informa del color de fondo, lo que puede ocurrir en algunas configuraciones de SSH o tmux. | |
GH_STACK_HYPERLINKS | ||
0, 1 | Deshabilita o habilita hipervínculos de OSC 8 cuando la detección de terminales es incorrecta. Los terminales no admitidos muestran la dirección URL completa de forma predeterminada. |
# Force the light palette for one command
GH_STACK_THEME=light gh stack view
Códigos de salida
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Error genérico |
| 2 | No está en una pila o no se encontró la pila |
| 3 | Conflicto de rebase |
| 4 | |
| GitHub Error de API | |
| 5 | Argumentos o marcas no válidos |
| 6 | Se requiere la desambiguación, porque la rama pertenece a varias pilas |
| 7 | Rebase ya está en curso |
| 8 | La pila está bloqueada por otro proceso |
| 9 | Las solicitudes de incorporación de cambios apiladas no están habilitadas para este repositorio |
| 10 | Se interrumpió la sesión de modificación y es necesario recuperarla. |