← Back to Blog
Git Workflow for Claude Code: Solo and Team Guide.
I ran feature branches on a one-person project for months. Here's the git system that actually works for solo Claude Code operators and teams.
I ran feature branches on a one-person project for months. Here's the git system that actually works for solo Claude Code operators and teams.
The right git workflow for Claude Code depends on one thing: whether you're building alone or with a team. I ran three feature branches on a one-person project for months and pushed almost none of them to GitHub. The worst one, chore/scrub-mcp-secrets, sat unmerged long enough to accumulate 191 files across accounting scripts, session logs, agent state, and a dozen other areas that had nothing to do with scrubbing secrets.
I'm Tom. I build AI systems professionally and teach Claude Code to solo operators and teams. I was using git and GitHub wrong for months. This is the system I switched to.
Git's entire branching model was designed to protect developers from each other. On a team, branches keep one person's unfinished work from breaking another person's day. That's the whole job.
When you're the only developer in the codebase, that problem doesn't exist. There's no one to protect the code from except past-you. Solo operators don't need branches as a workflow. They need a backup system, and the two things look similar on the surface while working completely differently underneath.
For solo operators: stay on master, commit after every Claude Code session, push to GitHub at natural checkpoints. For teams: one branch per task, kept short-lived, with Claude handling the commit message and PR description. Merge it and delete it immediately.
Claude Code runs git commands directly through natural language. You don't write the commands yourself. Tell Claude what you want, it stages the files, writes a commit message from the actual diff, and runs the push. This works in both the terminal version and the Desktop app.
If you're new to Claude Code and haven't set it up yet, the beginner's guide to Claude Code covers installation and your first session before you worry about git.
At the end of a session, say: "commit and push all the changes with a descriptive message." Claude stages the modified files, reads the diff, writes a commit message in conventional format, and pushes to origin. The whole operation takes about ten seconds and you never write a git command.
The Desktop Claude Code app works identically for git. Type the same instruction in the chat panel. Claude sees the same working tree and runs the same operations. The only difference is the interface, not the behavior.
By default, Claude Code adds a Co-Authored-By trailer to every commit it creates. GitHub reads this format and lists Claude as a co-author on that commit. To disable it, add one line to your CLAUDE.md: "Do not add Co-Authored-By attribution to commits."
Stay on master. Work directly on the main branch, commit at the end of every session, and push to GitHub when something meaningful is done.
GitHub, for a solo operator, is a backup drive. A safety net, not a ceremony. Push when you've shipped something worth keeping. That's the purpose.
The mistake most solo Claude Code operators make is copying team git workflows. They create a branch for every task, open a PR with no reviewer, and watch it sit for weeks until it's accumulated enough unrelated work to become a cleanup chore. That's exactly how a chore/scrub-mcp-secrets branch turns into 191 files.
Say: "commit and push everything with a descriptive message." Claude handles staging, writes the message from the diff, and pushes. For more context: "commit the API integration work and push — describe what was built and why." Claude reads what changed and writes accordingly.
You can also add a standing instruction to CLAUDE.md: "At the end of every session where meaningful work happened, commit and push all changes with a descriptive message." Claude reads this at session start and applies it automatically.
Create a branch when you're doing something you might want to roll back without losing other work. A risky refactor. An experiment you're not confident about. A significant architectural change where you want a clean escape route.
That's the signal: uncertainty, not organisation. If you're confident the work is going in, do it on master.
For teams, the right system is different but not complicated. One task gets one branch. The branch lives for hours or days, never weeks. Claude names it, commits on it, and drafts the PR description when the work is done. Merge it and delete it immediately.
The key is keeping branches short-lived. A branch open for more than a few days has accumulated too much context to review cleanly. Merge fast, delete immediately, and start fresh on the next task.
Ask Claude to name the branch based on the work: "create a branch for the payment webhook changes." Claude picks a name like feat/payment-webhooks, creates it, and checks it out.
For team consistency, put your naming convention in CLAUDE.md: "branches follow the format feat/<kebab-case-description> or fix/<kebab-case-description>." Claude reads it at session start and follows it from that point on.
Yes. Claude Code uses the gh CLI to create PRs directly from the terminal. Tell it: "create a PR for this branch with a summary of the changes." Claude reads all the commits on the branch, generates a title and description covering what changed and why, and opens the PR against your base branch.
The gh CLI needs to be installed separately: brew install gh on Mac, then gh auth login to connect it to your GitHub account. Once it's set up, Claude handles PR creation without you touching the GitHub interface.
Merge and delete on the same day the work ships. As soon as a PR merges, tell Claude: "delete this branch locally and on origin." One instruction.
To enforce this as a team habit, add it to your CLAUDE.md: "after merging a PR, always delete the branch locally and on origin."
Before: four open branches, the oldest three months old. When I dealt with it this morning, the catch-up commit was 191 files across 15 different areas of the project. Accounting scripts, session logs, agent state, call recording notes, a new copywriting wiki, all mixed together in a single branch that started as a two-hour secrets scrub. It took 20 minutes of cleanup before I could start anything new.
After: on master. Claude commits after every session. GitHub is a backup. Zero overhead.
The before state happened because I was following team-style git habits on a solo project. The fix was understanding that git's job changes entirely when you're the only person in the repo.
Git comes pre-installed on most Macs. Verify with git --version in your terminal. For PR creation, install the gh CLI: brew install gh, then gh auth login to connect it to your GitHub account.
Add this to your project's CLAUDE.md:
## Git conventions
- Commit messages use conventional commits: feat:, fix:, docs:, chore:
- Keep subject lines under 72 characters
- Commit before ending every session where meaningful work was doneClaude reads CLAUDE.md at the start of every session. The conventions apply automatically from that point.
If you're solo, add to CLAUDE.md: "Work on master directly. Commit and push at the end of every session where meaningful changes were made."
If you're on a team, add: "One branch per task. Naming format: feat/<description> or fix/<description>. Delete the branch locally and on origin immediately after the PR merges."
Create a remote repo with gh repo create or through the GitHub interface. Push your master branch once. After that, Claude's end-of-session commits push automatically to your remote, and your work is backed up with every session.
If you want a step-by-step walkthrough of the full Claude Code setup, the Blueprint covers the complete system including CLAUDE.md configuration, workflow patterns, and the folder structure I use for every project.
The most common one is copying team git workflows when you're solo. Branches and PRs exist to solve coordination problems between multiple developers. When you're the only person in the repo, adding them creates overhead without solving anything.
Not committing between sessions is the second issue. Claude Code sessions are stateless. The next session doesn't know what the previous one built unless it's committed to the git history. Uncommitted work means lost context if something goes wrong. Commit at the end of every session, without exception.
Treating GitHub as a deployment pipeline rather than a backup catches people too. For solo operators, GitHub is where the code lives safely offsite. It becomes a pipeline only if you deliberately set one up. Adding that complexity by default creates ceremony with no payoff.
The fourth is letting branches go stale. A branch open for more than a few days has accumulated too much to review cleanly. Merge it or close it. Dead branches create cleanup overhead and nothing else.
No, not by default. Claude Code commits when you ask it to. Say "commit and push everything with a descriptive message" at the end of a session and it handles staging, the message, and the push. You can add a standing instruction to your CLAUDE.md to make this happen at the end of every session automatically.
Generally, no. Solo operators don't need branches for day-to-day work. Stay on master, commit after every session, and use GitHub as a backup. Create a branch only when you're doing something you might want to roll back without affecting the rest of your work — a risky refactor, an experiment, a major structural change.
Tell Claude: "commit and push all changes with a descriptive message." It stages the files, writes a commit message from the diff, and runs the push. If you haven't set an upstream branch yet, Claude handles that step too. The gh CLI isn't needed for basic pushes.
Yes. Claude Code works with any git hosting provider, including GitHub. For standard git operations — commits, pushes, branches — it uses the git CLI directly. For GitHub-specific features like creating pull requests and managing issues, it uses the gh CLI, which needs to be installed separately.
One task per branch, kept short-lived. Ask Claude to name the branch, commit on it, and draft the PR description when the work is done. Merge and delete the branch immediately after the PR merges. Branches that stay open longer than a few days accumulate too much context to review cleanly.
Yes. Claude Code can read conflicting code and suggest resolutions based on what each side was trying to do. Tell it "help me resolve the merge conflicts in this file" and it walks through each conflict and proposes the right merge. You review and accept or adjust.
No. Git is local and works without any remote hosting. GitHub is optional. It becomes useful as a backup and for team collaboration. For a solo project where local git is enough, you don't need a GitHub account.
Git is supposed to serve the work. When Claude Code is handling the commits, the messages, and the pushes, the only question left is whether you're backed up. Answer yes, and get back to building.
If you want the complete Claude Code system — CLAUDE.md setup, session workflow, the folder structure I use across every project — it's all in the Blueprint.
Five interactive lessons. Install Claude Code, build your first automation, and deploy it live on the internet — all in under an hour. Free, no coding required.
Grab the Blueprint →