# A git workflow for Claude Code that keeps main clean

> The Claude Code git workflow we'd give anyone running several agents: a branch per task, small commits, read the diff, checks before merge, then squash.

Source: https://shuriken.sh/blog/claude-code-git-workflow

The Claude Code git workflow we'd give anyone running several agents: a branch per task, small commits, read the diff, checks before merge, then squash.

Story By Shuriken Updated 27 October 2026 4 min read

**Contents**

A good Claude Code git workflow is short: one branch per task, small commits as the agent goes, read the diff yourself, run the checks before anything merges, then squash it into one commit on main. Main only ever gets finished work. We learned most of it by getting it wrong with a lot of agent chats running at once.

## What goes wrong without one #

We build Shuriken with many agent chats working on one repository at the same time. Git counts more than 4,700 commits on our main branch between our first prerelease on 29 September and 22 October 2026. At that pace, every shortcut shows up.

The one that taught us most: several agents shared one working folder. One of them, wanting to prove a new test failed before its fix, put a shared file back to its old version for a moment. That wiped out another agent's edits to the same file, which nobody had committed yet. No error, no conflict. The work was gone.

Nothing about that was the model's fault. Two writers shared one folder and one branch. Git can only protect what's on a branch of its own and committed.

## 1. One branch per task, in its own worktree #

Give every task its own branch, and give every branch its own folder with git worktree. Then two agents can't touch each other's files, and throwing one attempt away never touches the other.

One branch and worktree per task keeps agents out of each other's files until each one merges.

Claude Code does this itself now. claude --worktree feature-auth creates a worktree under .claude/worktrees/feature-auth/ on a new branch named worktree-feature-auth, and when you exit it removes a clean worktree or asks before removing one with work in it ([Claude Code docs: Worktrees](https://code.claude.com/docs/en/worktrees)). Two things the docs suggest, and we'd second:

- Add .claude/worktrees/ to your .gitignore.
- Add a .worktreeinclude file listing gitignored files like .env that each new worktree needs.

We wrote more about why a [worktree per chat](https://shuriken.sh/blog/worktree-per-chat) is the right default, and the parallel setup itself is in our guide to [running Claude Code agents in parallel](https://shuriken.sh/guides/run-claude-code-agents-in-parallel).

## 2. Small commits while the agent works #

Ask for a commit after each step that works: "commit when the tests for this part pass". Small commits give you places to go back to that outlive the session. Claude Code's own checkpoints only cover edits made through its file tools ([Claude Code docs: Checkpointing](https://code.claude.com/docs/en/checkpointing)), and Anthropic's best-practice page says it plainly: "This isn't a replacement for git" ([Best practices](https://code.claude.com/docs/en/best-practices)). Our guide on [undoing Claude Code changes](https://shuriken.sh/guides/undo-claude-code-changes) goes through both.

On a task branch, the messages can be rough. They get squashed later.

## 3. Read the diff before anything merges #

git diff main...HEAD shows everything the branch changed. Read it. An agent's summary of what it did is not the diff, and the diff is what ships.

What we look for first: files the task had no reason to touch, tests that were changed to pass rather than code that was fixed, and anything that looks like a secret.

A second opinion helps here. Anthropic's best-practice page suggests having a fresh subagent review the diff, because it "sees only the diff and the criteria you give it, not the reasoning that produced the change" ([Claude Code docs: Best practices](https://code.claude.com/docs/en/best-practices)).

In Shuriken a chat can work on its own branch in its own worktree, and Finish merges it after your checks.

[Try Shuriken](https://shuriken.sh/)

## 4. Checks run before the merge, not after #

Write your checks down once, so the agent and you run the same ones: typecheck, unit tests, lint. Run them on the branch after it has caught up with main (git rebase main), not only before. A branch that passed yesterday can fail against today's main.

If a check fails, the fix goes back to the agent that made the branch. It knows what it changed.

## 5. Squash into main #

Squash-merge each task into one commit with a message that says what the change does. Main's history then reads as a list of finished tasks, one line each, and a bad one comes out with one git revert.

Then delete the branch and the worktree. Left-behind branches are how a repository ends up with forty worktree-* branches nobody remembers.

## How Shuriken does it #

We got tired of doing those five steps by hand, so they're built in. In Shuriken, every new chat starts on its own branch in its own git worktree (each project's one Main chat works on your own branch, for quick changes). When the work is done, Finish commits what's left, rebases onto your default branch, runs the checks you list in shuriken.json, squash-merges, and removes the branch and worktree. Or it opens a pull request with auto-merge on. A conflict or a failing check goes back to that chat's agent to fix. The details are in [Finish: checks, rebase and merge in one click](https://shuriken.sh/blog/finish-one-click-merge).

Every chat works on its own branch, and Finish at the top right merges it when the work is done.

A chat never closes over unmerged work, and dropping an attempt is one action: archive the chat. Its worktree folder goes, its branch stays in case you want the work back, and your main branch never saw it.

If you'd like the branch-per-task habit without the bookkeeping, [try Shuriken](https://shuriken.sh/).

Share

[X](https://x.com/intent/post?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fclaude-code-git-workflow&text=A%20git%20workflow%20for%20Claude%20Code%20that%20keeps%20main%20clean)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fclaude-code-git-workflow)[Hacker News](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fshuriken.sh%2Fblog%2Fclaude-code-git-workflow&t=A%20git%20workflow%20for%20Claude%20Code%20that%20keeps%20main%20clean)[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fclaude-code-git-workflow&title=A%20git%20workflow%20for%20Claude%20Code%20that%20keeps%20main%20clean)[E-mail](mailto:?subject=A%20git%20workflow%20for%20Claude%20Code%20that%20keeps%20main%20clean&body=https%3A%2F%2Fshuriken.sh%2Fblog%2Fclaude-code-git-workflow)

## Sources

- [Claude Code docs: Run parallel sessions with worktrees](https://code.claude.com/docs/en/worktrees) (accessed 22 October 2026)
- [Claude Code docs: Checkpointing](https://code.claude.com/docs/en/checkpointing) (accessed 22 October 2026)
- [Claude Code docs: Best practices](https://code.claude.com/docs/en/best-practices) (accessed 22 October 2026)

Parallel agents

Agents side by side, each on its own branch if you want.

A new chat gets its own branch and worktree unless you pick the project folder, so agents don't step on each other. Finish runs your checks and merges each one back.

[Try Shuriken](https://shuriken.sh/)

[How it works](https://shuriken.sh/features/parallel-agents)

## Keep reading

- [How Shuriken started: a tool we built for ourselves: Story 27 Oct 2026 4 min read We build software for clients and ourselves. No harness fit how heavily we use AI, so we built our own. Then a programmer asked: why don't we sell this?](https://shuriken.sh/blog/how-shuriken-started)
- [How to review AI-generated code without reading every line: Story 27 Oct 2026 5 min read We review agent diffs tests first: would each test fail without the change? Then deletions, the diff's edges, secrets, and a run. Our real misses.](https://shuriken.sh/blog/review-ai-generated-code)
- [Fork a chat from any reply, then merge it back: Update 27 Oct 2026 3 min read Try another approach without losing the first: fork a Shuriken chat from any reply, keep the fork under its parent, then merge its work back in.](https://shuriken.sh/blog/fork-and-merge-into)
- [Run a chat on another computer and keep going: Update 27 Oct 2026 4 min read Move a coding agent chat to another of your computers or a server. It stays the same chat, with its history and uncommitted work, and runs there.](https://shuriken.sh/blog/run-chat-on-another-computer)

## Free tools

- [Claude limit reset tracker](https://shuriken.sh/tools/limit-resets/claude)
- [Codex limit reset tracker](https://shuriken.sh/tools/limit-resets/codex)
