git-spice: stacked Git branches with offline state and multi-forge submission
Manage stacked Git branches
At a glance
- What is it?
- git-spice is a Go CLI that records branch stacking relationships in Git itself and turns them into pull requests on GitHub, GitLab, Bitbucket, Gitea or Forgejo. It is aimed at reviewers who want small diffs, and its main constraint is that the stack metadata lives in your local repository.
- Who is it for?
- Adopt git-spice if your team already reviews small branches and you want the stack relationship tracked locally with gs branch create and submitted in one pass with gs stack submit. Skip it if your forge is not one of GitHub, GitLab, Bitbucket, Gitea or Forgejo, since the submission path is the part that has no fallback.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The review bottleneck git-spice is built around
A large feature branch is hard to review because the diff mixes unrelated changes. Splitting it into a chain of branches fixes the review, then creates a new problem: keeping the chain rebased. When the bottom branch changes, every branch above it needs a rebase, and each rebase can conflict. Doing that by hand across five branches is an afternoon of git rebase --onto and force pushes. git-spice targets that maintenance cost specifically. It is for people who already believe small pull requests get better review, and who are willing to run a wrapper command instead of raw git for branch creation. The README frames the workflow as stacking branches, navigating them, modifying and rebasing them, then creating pull requests or merge requests from them. Nothing in the material suggests it is meant for solo work on a single branch, where a stack has no reason to exist.
Where the stack graph is stored and what stays offline
The README claims completely offline operation with no external dependencies until you push or pull from a remote repository. That claim only holds if the parent-child relationships between branches are stored somewhere that is not a server. The repository description and the command surface point to Git itself as that store, with git-spice maintaining its own record of which branch sits on which. This is the design decision that separates it from forge-side stacking tools: the graph is local state, so branch create and restack work on a plane. The trade-off is that the graph is not shared. A teammate who clones the repository gets the commits but not necessarily the stack relationships, and the supplied material does not say whether that metadata is pushed with the branches or reconstructed on sync. Treat that as the first thing to check in a real repository rather than something the README settles.
The command sequence from the README
The README gives a concrete example. You stack a branch on the current branch with gs branch create feat1, then stack another on top of it with gs branch create feat2. Submitting the whole chain is a single gs stack submit, which the README says creates pull requests for feat1 and feat2. To pick up upstream changes and remove branches that have already merged, you run gs repo sync. To move the remaining branches onto the updated base, you run gs stack restack. The README also documents CLI shorthands, so gs bc feat1, gs ss, gs rs and gs sr are equivalent to the long forms. The ordering matters: sync first, then restack. Running restack against a stale base is the kind of mistake the two-command split is designed to make visible, and it is worth internalising before you script anything around it.
Forge coverage and the submission boundary
Submission is where git-spice stops being a local convenience and starts depending on a host. The README lists GitHub, Bitbucket, Gitea and Forgejo pull requests, plus GitLab merge requests, and names Codeberg as a Forgejo host. Offline operation ends at the push. This is a narrower footprint than a plain git remote, which works with any server that speaks the protocol. If your team runs a self-hosted forge outside that list, the stack management still works but the one-command submission does not, and you are back to opening pull requests by hand while git-spice tracks the graph. That is a real boundary, not a temporary gap, and it should decide adoption more than any other single fact in the README.
What the README does not answer
The README is short and promotional in tone, and it leaves operational questions open. It does not describe what happens when a restack hits a conflict, beyond the implication that you resolve it as you would any rebase. It does not say how gs repo sync decides a branch has merged, which matters because deleting the wrong local branch is annoying and deleting the wrong remote branch is worse. It does not document the configuration file, so there is no way from this material to know where per-repository settings live or how to point git-spice at a self-hosted instance. The full documentation is hosted separately at abhinav.github.io/git-spice, and the CLI shorthand page is the only documentation URL the README links by name. Anyone evaluating this should read the hosted docs before trusting the example sequence, because the example is a happy path with no failure branch.
How it compares to plain git rebase --onto
The alternative most engineers already have is manual rebasing. You keep a mental or written note of the branch order, and when the base moves you run git rebase --onto newbase oldbase branch for each branch in turn, then force push each one. That approach has no dependencies, works with any forge, and requires no new tool. What it lacks is a record of the stack: the ordering lives in your head or a text file, and nothing can tell you that feat2 sits on feat1. git-spice replaces the note with tracked metadata and replaces the per-branch rebase loop with gs stack restack. The cost is a new command vocabulary, a local state file you should understand before you rely on it, and a forge support list that is narrower than git itself. If your stacks are two branches deep and rare, manual rebasing is a defensible choice. If they are five deep and constant, the metadata earns its keep.
Licence and upgrade cost
git-spice is distributed under GPL-3.0, and the README includes the standard copyright notice naming Abhinav Gupta and 2024. For a command line tool you install and run, that is unremarkable. It becomes a consideration if you intend to vendor the source into a product or link it into a larger distributed work, because GPL-3.0 carries copyleft obligations that permissive licences do not. This is a description of the licence text, not legal advice; if you plan to redistribute anything derived from it, get your own reading. On upgrades, the release history shows v0.31.0, v0.31.1 and v0.31.2 landing within about a week of each other in July 2026, with a push to main in September 2026. That cadence suggests patch releases arrive quickly, which is good for fixes and awkward if you pin versions loosely in a shared environment. Pin a specific version in whatever installs it, and read the release notes before moving the pin, because the project is pre-1.0 and the command surface is still being adjusted.
Editorial conclusion
Adopt git-spice if your team already reviews small branches and you want the stack relationship tracked locally with gs branch create and submitted in one pass with gs stack submit. Skip it if your forge is not one of GitHub, GitLab, Bitbucket, Gitea or Forgejo, since the submission path is the part that has no fallback. Before rolling it out, verify two things on a throwaway clone: that gs repo sync deletes only the branches you expect, and that the stack metadata survives a fresh clone, because the README does not describe either behaviour in detail.
Community notes