Branch stacks and publication
A stack splits related work across a sequence of branches. Each layer depends on the previous one, so reviewers can inspect smaller changes. Riff separates organizing the branches on your computer from publishing them to the host.
Build a linear stack
Open Stacks for the active repository. Choose an existing branch or create a new layer, then select its parent. For example:
| Layer | Parent |
|---|---|
feature/data |
main |
feature/api |
feature/data |
feature/ui |
feature/api |
Make each layer's changes on its corresponding branch. When associating an existing branch, the parent's current commit must be an ancestor of that branch. Register the relationship before advancing or rewriting the parent. Removing a layer's association leaves the branch and commits intact; detach dependent layers first.
Riff supports a linear chain of up to 25 layers, with up to 200 commits per layer. A tracked layer can have one child in the chain. Merge commits, cycles and incompatible ancestry are refused.
Preview and run restack
Restack reapplies each layer's commits onto its updated parent.
- Commit or stash pending edits and finish any Git operation in progress. Branches involved must be available, rather than checked out in another worktree.
- If ignored files prevent the operation, move them outside the working tree and inspect the repository again. Riff does not delete or automatically stash them for restack.
- Select a layer and load the preview. Review the complete chain, parent branches, commit counts and any published-history warning. That warning uses remote references already present on your computer; it is not a fresh server query.
- Confirm the reviewed plan. Riff saves recovery references before rewriting and checks the branches and commits again. Hooks and configured signing remain active.
Restack performs no push. Rewriting an already published branch can require a separate decision about remote history; the publication workflow below will not force-push it.
Continue a conflict or stop the sequence
Open each conflicted file inside the stacks dialog, review the result and save it. Continue after resolving the remaining conflicts. The recorded session can be resumed after restarting Riff when the repository still matches it.
Stop remaining layers preserves completed layers. During a conflict, finish the current resolution and continue once so the stop takes effect after that layer. This is not a rollback of the whole stack. If another process changed the repository or an interrupted step cannot be confirmed, inspect the state and the retained recovery references before proceeding.
Publish linked pull requests
- Open the publication area in Stacks and select the remote and a compatible host connection. Each layer must have commits, be based on its current parent and be ready for a normal push. The remote base must match the reviewed base.
- Load the publication preview. Check each source branch, target branch, commit, title and description. The first pull request targets the base; each later request targets the preceding layer.
- Confirm publication. Riff sends the reviewed revisions and creates the requests in order. It reuses a compatible existing pull request; an incomplete host query cannot establish that no request exists.
- Read the result for each layer and open the host links to continue the review.
The selected connection supplies the host API permissions. HTTPS Git operations use the selected credentials; SSH keeps your configured SSH authentication. The workflow does not merge requests, delete branches, update submodules or force-push divergent history.
Resume a partial publication
Progress is recorded by layer. Pausing stops the next steps and keeps branches and requests already published. Resume after resolving a definite connection or permission refusal; Riff checks the repository, identity and remote state again.
A request can have an uncertain result if the host received it but the response was lost. Riff checks the host before continuing and does not automatically repeat creation merely because the request is absent from a query. Inspect the host and the displayed status; an uncertain session cannot be discarded through the normal flow. Publication is not an all-or-nothing transaction across Git and the host.
See conflicts and recovery for recovery points, or work contexts for worktrees and session contexts.