git-spice review: stacked Git branches without leaving your terminal

The problem git-spice solves, and who it is for

Splitting a large change into reviewable pieces usually means a chain of branches, each one based on the previous. Git itself has no concept of that chain. When the bottom branch changes, you rebase every branch above it by hand, and when you open pull requests, each one has to point at the right base. git-spice exists to hold that chain as a first-class object. The README describes it as "a tool for stacking Git branches" that lets you "manage and navigate stacks of branches, conveniently modify and rebase them, and create GitHub, Bitbucket, Gitea, or Forgejo Pull Requests or GitLab Merge Requests from them." The audience is narrow on purpose: developers who review through one of those forges and are comfortable running commands rather than clicking through a web UI. If your team merges straight to main and never stacks, this tool adds a layer of state you do not need.

How the branch stack is actually tracked

git-spice is a single Go binary that wraps Git rather than replacing it. The repository root contains one file per command group (branch.go, branch_create.go, branch_restack.go, downstack.go, stack operations, auth.go, commit.go), which tells you the surface is a command tree over ordinary Git operations. The README claims "completely offline operation with no external dependencies until you push or pull from a remote repository," so stack metadata lives locally and the forge is only contacted when you submit or sync. That design has a consequence worth naming: the stack is not stored in the Git history itself, so a colleague who clones the repository sees normal branches and no stack relationship. The stack is your local view, reconstructed from the branches you told git-spice to track. The README also states you can "keep using your existing workflow and adopt git-spice incrementally," which fits that model. Nothing forces you to convert an existing branch set at once.

Installing git-spice and running a first stack

The README does not give an install command. It points to the project site at https://abhinav.github.io/git-spice/ for full documentation, so that page is where the installation instructions live, and the release list shows v0.31.2 as the most recent tagged build. Once the gs binary is on your PATH, the workflow in the README is a sequence of branch creations. This block creates two branches, each stacked on the one below it:

# Stack a branch on top of the current branch.
$ gs branch create feat1

# Stack another branch on top of feat1.
$ gs branch create feat2

After that, the README submits both branches as pull requests in one step:

$ gs stack submit

The same commands have shorthands, which the README lists explicitly. This block is the equivalent of the two above, and the shorthand names are the ones to memorize if you use the tool daily:

gs bc feat1  # branch create feat1
gs bc feat2  # branch create feat2
gs ss        # stack submit
gs rs        # repo sync
gs sr        # stack restack

Two more commands matter after the first push. repo sync pulls the latest changes from the remote and deletes branches that were merged, and stack restack rebases the remaining branches onto the updated base. The README presents them in that order, which is the order that works: sync first, then restack.

Where git-spice gets in the way

The forge list is the hard boundary. GitHub, GitLab, Bitbucket, Gitea and Forgejo are supported, with Codeberg named as an example of a Gitea or Forgejo host. If your team reviews on a host outside that set, the submit half of the tool does nothing for you, and you are left with a branch manager that still needs manual pull requests. The offline claim cuts both ways too: because the stack is local metadata until you push, a machine that loses its git-spice state loses the stack relationships, and the README does not document rollback or recovery for that case. Restacking is also a rebase, so a conflict in the middle of a stack stops the chain and you resolve it the way you would resolve any Git conflict. The tool does not make conflicts disappear; it makes them happen in a predictable place. Finally, the README does not document an upgrade procedure, so anyone running an older binary has to read the changelog before moving to v0.31.2.

git-spice compared with Git Town and Graphite

Graphite is the closest comparison people search for, and the difference is where the work happens. Graphite pairs a CLI with a hosted web dashboard for review, which means stack state and review state live in a service you sign into. git-spice keeps the whole loop in the terminal and talks to the forge you already use, so there is no separate account and no dashboard to check. Git Town is the other comparison worth making, and it approaches the same problem from a different angle: it automates branch synchronization and shipping through a broader set of Git workflow commands, and it is not tied to one forge's review model the way git-spice's submit flow is. If you want a tool that manages the branches and leaves review entirely to the forge you already have, git-spice is the narrower fit. If you want a hosted review surface with stacked diffs built in, neither git-spice nor Git Town is that.

Maintenance, releases and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-07, which is recent enough to call the project maintained. Releases are frequent: v0.31.0, v0.31.1 and v0.31.2 all landed between 2026-07-13 and 2026-07-21, and the repository carries a .changie.yaml plus a .changes directory, which is the tooling behind the CHANGELOG.md. That means upgrade cost is mostly reading the changelog for the version you are moving to, since the README does not describe an upgrade path or a self-update command. The licence is GPL-3.0, stated in the README and in the LICENSE file. For most engineers running a CLI, that is a non-issue. For anyone considering embedding git-spice in a distributed product, the copyleft terms are the thing to read, and this article is not legal advice. The Go module path is go.abhg.dev/gs, so a Go build is possible from source, but the README does not document that route.

What to verify before you standardize on it

Check three things in order. First, confirm your forge is on the supported list, because that decides whether stack submit is useful to you at all. Second, run gs auth status after installing, since the auth command group exists in the repository root and credentials are what the submit path depends on. Third, read the changelog entry for the version you install. The README gives the day-one workflow but says nothing about what happens when a stack goes wrong, and the repository layout shows no recovery command beyond restack and sync. If your team's review process is already comfortable with plain branches and short-lived pull requests, the incremental adoption path the README describes means you can try git-spice on one stack without converting anything else. That is the cheapest way to find out whether the local-stack model matches how your team actually reviews.

Editorial conclusion

Adopt git-spice if you already work in a terminal, your team reviews pull requests on GitHub, GitLab, Bitbucket, Gitea or Forgejo, and your main pain is rebasing a chain of dependent branches by hand. Do not adopt it if your team reviews on a host outside that list, or if you need a browser UI before you will trust the tool. Before committing, run gs auth status to confirm the CLI can see your credentials, and check the release notes for the version you install, because the changelog is the only place upgrade behaviour is documented.

Frequently asked questions

Official sources

1. abhinav/git-spice on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases