Pilas de ramas y publicación

Una pila de ramas (stack) divide trabajo relacionado en una secuencia de ramas. Cada capa depende de la anterior y permite revisar cambios más pequeños. Riff separa la organización de las ramas en tu equipo de su publicación en el proveedor.

Crear un stack lineal

Abre Stacks para el repositorio activo. Elige una rama existente o crea una capa y selecciona su rama padre. Por ejemplo:

Realiza los cambios de cada capa en su rama correspondiente. Al asociar una rama existente, el commit actual del padre debe ser un ancestro de ella. Registra la relación antes de avanzar o reescribir el padre. Quitar la asociación conserva la rama y sus commits; desasocia primero las capas dependientes.

Riff admite una cadena lineal de hasta 25 capas, con hasta 200 commits por capa. Una capa registrada puede tener una hija en la cadena. Los commits de merge, los ciclos y los ancestros incompatibles se rechazan.

Revisar y ejecutar el restack

El restack vuelve a aplicar los commits de cada capa sobre su padre actualizado.

1. Guarda las ediciones pendientes en un commit o stash y termina cualquier operación Git en curso. Las ramas implicadas deben estar disponibles, sin checkout en otra worktree.
2. Si los archivos ignorados impiden la operación, muévelos fuera del árbol de trabajo y vuelve a comprobar el repositorio. Riff no los elimina ni los guarda automáticamente en un stash para el restack.
3. Selecciona una capa y carga la vista previa. Revisa la cadena completa, las ramas padre, los recuentos de commits y el aviso de historial publicado. El aviso usa referencias remotas ya presentes en tu equipo; no es una nueva consulta al servidor.
4. Confirma el plan revisado. Riff guarda referencias de recuperación antes de reescribir y vuelve a comprobar ramas y commits. Los hooks y la firma configurada siguen activos.

El restack no hace push. Reescribir una rama ya publicada puede requerir una decisión aparte sobre el historial remoto; el flujo de publicación siguiente no hace push forzado.

Continuar un conflicto o detener la secuencia

Abre cada archivo en conflicto en el diálogo de stacks, revisa el resultado y guárdalo. Continúa después de resolver los conflictos restantes. La sesión registrada puede reanudarse tras reiniciar Riff si el repositorio sigue correspondiendo a ella.

Detener las capas restantes conserva las capas completadas. Durante un conflicto, termina la resolución actual y continúa una vez para detenerte después de esa capa. Esto no deshace todo el stack. Si otro proceso ha cambiado el repositorio o no se puede confirmar un paso interrumpido, revisa el estado y las referencias de recuperación conservadas antes de continuar.

Publicar pull requests enlazados

1. Abre el área de publicación de Stacks y selecciona el remoto y una conexión compatible con el proveedor. Cada capa debe tener commits, partir de su padre actual y permitir un push normal. La base remota debe corresponder a la base revisada.
2. Carga la vista previa de publicación. Comprueba origen, destino, commit, título y descripción de cada rama. El primer pull request apunta a la base; cada uno de los siguientes apunta a la capa anterior.
3. Confirma la publicación. Riff envía las revisiones comprobadas y crea las solicitudes en orden. Reutiliza un pull request existente compatible; una consulta incompleta al proveedor no demuestra que no exista una solicitud.
4. Lee el resultado de cada capa y abre los enlaces del proveedor para continuar la revisión.

La conexión seleccionada aporta los permisos de la API del proveedor. Las operaciones Git por HTTPS usan las credenciales seleccionadas; SSH mantiene la autenticación SSH configurada. El flujo no fusiona solicitudes, elimina ramas, actualiza submódulos ni fuerza el envío de historial divergente.

Reanudar una publicación parcial

El progreso se registra por capa. Pausar detiene los pasos siguientes y conserva las ramas y solicitudes ya publicadas. Reanuda después de corregir un rechazo confirmado de conexión o permisos; Riff vuelve a comprobar el repositorio, la identidad y el estado remoto.

Una solicitud puede tener resultado incierto si el proveedor la recibió pero se perdió la respuesta. Riff consulta al proveedor antes de continuar y no repite automáticamente la creación solo porque la solicitud no aparezca en una consulta. Comprueba el proveedor y el estado mostrado; una sesión incierta no puede descartarse mediante el flujo normal. La publicación no es una única transacción entre Git y el proveedor.

Consulta conflictos y recuperación para puntos de retorno o contextos de trabajo para worktrees y contextos de la sesión.