Git Alternatives in 2026: What Works for AI Agent Workflows

The git alternatives worth using with AI coding agents in 2026 are Jujutsu (jj), GitButler and Sapling, and all three sit on top of a git-compatible repository, so you do not have to leave GitHub to try them. Git-native patterns (worktrees, stacked pull requests, merge queues) solve most of the same problems with no new tool.

The older alternatives (Mercurial, Fossil, Pijul) predate agents and have no agent-specific story. This guide goes through the problems agents create and maps each to the tool that handles it. Commands below were run on 29 October 2026 with jj 0.46.0 and git 2.51.0.

Why agents change the git alternatives question

Git was designed for a human who edits one working copy, stages deliberately and commits a few times a day. An agent edits several files in one pass, runs many times in parallel, and produces changes faster than anyone reviews them.

Anthropic described the extreme version on its engineering blog. In "Redesigning source control" (anthropic.com/engineering/redesigning-source-control, 13 October 2026), it says: "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day." It built an internal system called Scion, and states: “Scion is by no means a suitable replacement for git for general use.” The post credits prior art: "Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling." It also says "it’s difficult to offer Scion in a form that would be broadly useful to other organizations." Scion is internal, but its lineage points at the tools below.

Most teams are nowhere near that volume. They still hit the same four problems earlier than they expect.

Problem 1: running several agents at once

Git worktrees give each agent its own directory and branch from one repository, and git refuses to check out the same branch twice. That refusal is the safety feature: two agents cannot silently write to the same branch.

git clone https://github.com/octocat/Hello-World app && cd app
git worktree add -b agent-a ../app-agent-a
git worktree add -b agent-b ../app-agent-b
git worktree list

Preparing worktree (new branch 'agent-a')
HEAD is now at 7fd1a60 Merge pull request #6 from Spaceghost/patch-1
Preparing worktree (new branch 'agent-b')
HEAD is now at 7fd1a60 Merge pull request #6 from Spaceghost/patch-1
.../app          7fd1a60 [master]
.../app-agent-a  7fd1a60 [agent-a]
.../app-agent-b  7fd1a60 [agent-b]

Start one agent session in each of app-agent-a and app-agent-b. Trying to reuse a branch fails as intended:

$ git worktree add ../x agent-a
fatal: 'agent-a' is already used by worktree at '.../app-agent-a'

All worktrees share one object store, so a second checkout costs the working files, not a second clone. The git documentation (git-scm.com/docs/git-worktree) describes this as managing multiple working trees attached to the same repository. The catch: worktrees isolate files, not intent. Two agents can still change the same function on different branches and meet at merge time.

GitButler takes the opposite approach: parallel branches in one working directory. Its repository (github.com/gitbutlerapp/gitbutler, October 2026) describes a Git-based tool "designed for ease of use and modern agentic workflows", with parallel and stacked branches that restack when you amend a commit, a GUI and a but CLI, and hooks or skills for agent systems. Its docs have a parallel-agents guide for running several agents in one workspace without separate worktrees. The license is Fair Source (FSL-1.1-MIT), which becomes MIT after two years. Pick it when one person supervises several agents in a single checkout and wants a visual lane per agent.

Problem 2: undoing and reshaping what an agent did

Jujutsu records every repository operation and undoes any of them with jj undo, and the working copy is always a commit, so an agent's half-finished edit is already saved. There is no staging area and no stash. Jujutsu's README (github.com/jj-vcs/jj, Apache 2.0) states the working copy is a real commit that is amended automatically, and that it is experimental overall, with the Git backend the only production-ready one.

We cloned a small public repository and played the part of an agent that touched two unrelated files in one pass:

jj git clone --colocate https://github.com/octocat/Hello-World hw && cd hw
jj new master -m "add usage notes"
# the agent edits README and creates USAGE.md
jj status

Working copy changes:
M README
A USAGE.md
Working copy  (@) : mlxnyzxv cfaf2a68 add usage notes
Parent commit (@-): orrkosyo 7fd1a60b master | (empty) Merge pull request #6 ...

Reviewing is easier when one change does one thing, so split it:

$ jj split -m "docs: add USAGE.md" USAGE.md
Selected changes : mlxnyzxv d780aac5 docs: add USAGE.md
Remaining changes: qyuluxzn f1d4f738 add usage notes

$ jj describe -m "docs: extend README"
$ jj log -r "master::@"
@  qyuluxzn demo@example.com 2026-10-29 23:29:39 a2dde85b
│  docs: extend README
○  mlxnyzxv demo@example.com 2026-10-29 23:29:39 d780aac5
│  docs: add USAGE.md
◆  orrkosyo octocat@nowhere.com 2012-03-07 04:36:50 master 7fd1a60b
│  (empty) Merge pull request #6 ...

Then a branch (jj calls them bookmarks), a push preview, and an undo:

$ jj bookmark create agent-a -r @
$ jj git push --dry-run --bookmark agent-a
Changes to push to origin:
  bookmark: agent-a [add to a2dde85bff27]
Dry-run requested, not pushing.

$ jj undo
Undid operation: 402a854af0bc ... create bookmark agent-a pointing to commit a2dde85bff27...

jj op log shows a snapshot working copy operation recorded by the jj status call, which is the property that matters for agents: the edit entered history without anyone running a commit. Plain git gets there with git reflog and discipline, not by default.

Underneath, git log in the same directory shows the commits, because we cloned with --colocate (a .git directory next to .jj). Teammates and CI see an ordinary git repository. Jujutsu also records conflicts inside commits instead of stopping the operation, so a rebase over many agent commits finishes and you resolve conflicts later. The jj repository calls this first-class conflicts.

Problem 3: landing many small changes

Stacked pull requests split one large change into linked small ones, each reviewed and merged separately, and GitHub now documents them natively. Its docs (docs.github.com, "About stacked pull requests", checked 29 October 2026) define a stack as two or more pull requests in one repository where the bottom targets the trunk and each upper one targets the branch below, merged from the bottom up. The gh stack GitHub CLI extension handles the local workflow, and the docs include a page on using stacks with Jujutsu, Sapling or git-town. GitHub's changelog announced a public preview on 30 July 2026 and general availability on 6 October 2026 (github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available).

Beyond the native feature, three other tools stack pull requests:

Agents suit stacks. A coding agent asked for a feature tends to produce one large diff; asking it to commit in reviewable layers is a prompt change, and the stack tool does the rest. Reviewers read small diffs, and our guide on pull request size covers why that matters for review quality. The agent-scale review problem itself is in code review at agent scale.

Problem 4: merging at high volume

A merge queue tests each pull request together with the latest base and the ones ahead of it, so ten individually green agent PRs cannot break main when combined. GitHub's merge queue docs (October 2026) describe temporary merge_group branches, first-in-first-out merging, and removal of a failing PR with the rest rebuilt without it. Your CI workflows must run on the merge_group event or required checks never report.

Mergify's merge queue (docs.mergify.com, October 2026) adds batching and speculative checks; its own comparison page lists up to 128 parallel speculative checks against 100 for GitHub's queue. That is the vendor's figure, so benchmark it on your CI. Graphite also lists a merge queue in its docs.

Past a certain volume the queue stops being enough, which is the territory Anthropic wrote about. The Sapling repository (github.com/facebook/sapling, GPL-2.0, ISL under MIT) is Meta's answer: a client that clones and works with git repositories, an Interactive Smartlog web UI (ISL), and a server component, Mononoke, which the page says is used in production at Meta but "not yet supported for external usage". For a team, that means Sapling the client is usable today against GitHub, while the server-side scaling story is not something you can adopt.

Comparison table

Older alternatives, no agent-specific story

Mercurial (7.2 on mercurial-scm.org, January 2026), Fossil and Pijul are maintained systems, but we found nothing on their own sites about agent workflows, so we do not recommend them for it.

Which to pick

• Pick plain git with worktrees if you run two to five agents and want no new tooling. Add stacked PRs once diffs get large.
• Pick Jujutsu if you want the working copy always saved, cheap undo and easy reshaping, and you are happy to work in a colocated repo beside git. Expect experimental software.
• Pick GitButler if you supervise agents visually in one checkout.
• Pick Sapling if you work in a very large repository and like the smartlog and stacked workflow; do not plan on Mononoke.
• Add a merge queue the day agent PRs start colliding on main.

Where repowise fits

repowise does not replace your version control; it reads git history, so it works with whatever sits on top of git. In our test we ran repowise init --yes --no-prose --no-editor-setup inside the colocated Jujutsu clone above, then asked for one file's history:

$ repowise risk --target README
README: history only, 2 commits, last 2011-09-14, primary owner Johnneylee Jack Rollins (50% of commits)

That is a tiny repository, so it proves ingestion, not scale. We tested a Jujutsu colocated repository only; we did not test Sapling, so we make no compatibility claim for it. The history layers behind this are described in git intelligence: hotspots, ownership, co-change and fix history, which tell an agent which files are risky before it edits them.