Mergify Stacks vs gh⁠-⁠stack

GitHub released gh-stack, a stacking extension for the gh CLI. Both tools solve the same problem (big PRs are hard to review, so split them into a chain of small ones), but they take different approaches to get there.

The biggest difference is how each tool thinks about branches.

Both produce the same result on GitHub: chained PRs where each targets the previous one’s branch. The difference is what you deal with locally.

You work on a single branch. Each commit maps to a PR automatically:

Under the hood, mergify stack push creates a remote branch per commit and chains the PRs:

You never see or manage these remote branches. They’re an implementation detail.

You create and name a separate branch for each change. Each branch becomes a PR that targets the branch below it:

Three branches, three PRs: feat/model targets main, feat/endpoint targets feat/model, feat/tests targets feat/endpoint. You navigate between them with gh stack up and gh stack down.

Simpler workflow. One branch, standard Git. You don’t create branches or navigate between them. You commit and rebase like you already do. The branching complexity lives on the remote side where you don’t have to think about it.

One command does more. mergify stack push rebases on the target branch, pushes all changes, and creates or updates PRs in a single command. With gh-stack, pushing and creating PRs are separate steps (push then submit).

Merge Queue depth. Mergify’s Merge Queue has batching, priority lanes, speculative checks, and queue freeze. gh-stack relies on GitHub’s built-in merge queue, which is more limited.

Collaboration support. mergify stack checkout lets a teammate pick up your stack locally and push changes. mergify stack sync pulls remote changes back down, so commits made by bots or review suggestions are incorporated automatically. With gh-stack’s force-push model, coordinating on the same stack is harder.

Merge works today. Stacked PRs land through the Merge Queue as each dependency merges. gh-stack’s merge command is listed in the docs but not yet implemented.

Native GitHub UI. gh-stack gets a stack map rendered directly in the PR interface. Mergify posts a stack comment on each PR, which works well but is a comment rather than a native UI element.

Platform lock-in. gh-stack is GitHub-only by design. Mergify’s stacking workflow also targets GitHub today, but the architecture isn’t tied to a single platform.

Distribution. gh-stack ships as a gh CLI extension and will likely get deeper GitHub integration over time. Mergify CLI is a standalone install (uv tool install mergify-cli).

Pricing. Both are free. Mergify Stacks is a standalone CLI that doesn’t require a Mergify subscription.

If you’ve been using gh-stack and want to try Mergify Stacks, the migration is straightforward. The main shift is moving from “one branch per PR” to “one commit per PR on a single branch.”

uv tool install mergify-cli
mergify stack setup

This installs the CLI and adds a commit-msg hook that generates Change-Ids for your commits. See the setup guide for details.

With gh-stack:

gh stack init
# work on first change
gh stack add
# work on second change
gh stack push
gh stack submit

With Mergify Stacks:

mergify stack new
git commit -m "first change"
git commit -m "second change"
mergify stack push

The result on GitHub is the same: two chained PRs, each showing one change.