Git Workflow with Claude Code: Automate Commits and PRs (2026)

Can Claude Code create commits and PRs on its own?

Yes - and it is a built-in capability, nothing extra to install. Claude Code calls git and gh through its Bash tool, so you just say "commit the changes" and it runs git status and git diff, reads the context, then drafts a commit message. Say "create a pr" and it runs gh pr create, generating the title and body from your commits.

Minimum requirements: the repo must be initialized with git init and you have to be inside it. To open a PR you also need the gh CLI (GitHub CLI) logged in. If you do not have it, Claude Code still commits fine - it just cannot open the PR for you. Per Anthropic's common workflows documentation (accessed 08/09/2026), these are officially supported flows, not third-party hacks.

One trust note up front: Claude Code touches git through the Bash tool's permission layer, so every write command (commit, push) asks for your approval unless you have pre-granted it. It does not push to a remote unless you ask - but as the end of this article covers, you should still spell that out in CLAUDE.md to be certain.

Step 1 - Set up: git, the gh CLI, and auth

Before handing git over to the agent, check three things. Open a terminal (or let Claude Code run it for you) and confirm:

git --version
gh --version
gh auth status

If gh reports that it is not installed, install the GitHub CLI and log in once:

# macOS
brew install gh
# Windows
winget install --id GitHub.cli
# After installing, log in (opens a browser to authenticate)
gh auth login

Choose GitHub.com then HTTPS then authenticate in the browser. Once this is done, gh holds a token so it can open PRs on your behalf. Finally, make sure you are in the right repo and on a working branch:

git rev-parse --is-inside-work-tree # true if this really is a git repo
git branch --show-current

Tip: do not work directly on main. Create a branch first - you can even ask Claude Code to do it: "create a branch feat/checkout and switch to it". A clean branch makes the final PR step a lot tidier.

Step 2 - Auto-write proper conventional commits

This is where Claude Code shines. After you finish coding, instead of typing the message yourself, give the instruction:

commit the current changes using conventional commits

Claude Code runs git status and git diff --staged (plus the unstaged diff), analyzes what you actually changed, then writes a message in the right format:

type(scope): short description in the present tense

- bullet detail if needed
- the reason for the change, not just a file list

The common Conventional Commits type values:

Tip for higher-quality messages: if you have already staged exactly the part you want to commit (a deliberate git add), Claude Code sticks to the staged diff and guesses less. You can also be specific: "commit, scope is 'checkout', focus on why it changed instead of listing files". The more context you give it about why the change happened, the more useful the message stays for whoever reads the history later.

About the "Co-Authored-By" line: by default Claude Code often appends attribution like Co-Authored-By: Claude <...> at the end of a commit. On a personal repo or side project, keeping it is harmless and transparent. But on a company repo with strict commit conventions (or CI that lints message format with commitlint), you may want it off. The simplest fix is a rule in CLAUDE.md: "do not add a Co-Authored-By line or any AI signature to commit messages" - Claude Code will comply. This is a repo-policy decision, so agree it with your team before flipping it on or off across the board. If you want a quick reference for the git commands you use most with Claude Code, the Claude Code cheat sheet has a handy lookup table.

Step 3 - Split commits by type/scope (auto-split)

In practice you rarely change just one thing. A single coding session might add a feature, fix a bug, and update docs all at once. Cram all of it into one giant commit and reviewers suffer, and a revert drags along unrelated changes. Claude Code can split it for you:

these changes span several types. Split them into separate atomic
commits by type/scope, one type of change per commit

It groups the diff by topic, stages each group (git add -p or by file), then creates the commits one by one. A mixed diff might become:

feat(payment): add VietQR payment flow
fix(payment): correct amount rounding
docs(payment): note the SEPAY_KEY environment variable

Why it is worth it: each atomic commit is an independent unit of review, the history reads clearly, and when you need git revert you remove only the broken thing without touching the rest. This is a technique almost no guide mentions, yet it is the big difference between "let the AI commit whatever" and "let the AI commit like a careful dev". One caveat: skim the commits it proposes before approving them - occasionally the scope boundaries it draws do not match your module structure, in which case just say "merge the first two commits".

Step 4 - Scan for secrets before committing

Here is a real risk of letting an agent commit that almost no guide mentions: the agent can accidentally slip a .env, an API key, a token, or a database connection string into a commit - and once it is in the history, scrubbing it out cleanly is a pain. Before committing, ask it to scan:

before committing, scan the staged files for any secrets:
API keys, tokens, passwords, connection strings, or a stray .env file

The safety checklist worth applying:

• Have a .gitignore that blocks .env, *.pem, *.key from the very start of the repo.
• Ask Claude Code to inspect the staged diff for key-like or token-like strings before every commit.
• Install a pre-commit hook that blocks at the git layer (for example gitleaks or git-secrets) so you do not depend entirely on the agent.
• If you already committed a secret: treat that token as leaked - rotate it now, do not just delete the file and commit over it.

To fully automate this part, you can move the scan into a hook that runs before the commit - see how to use hooks in Claude Code to wire in an automatic check. The golden rule: never fully trust an agent with write access to your history without a blocking layer at the git level.

Step 5 - Open a pull request automatically with gh

Once the commits are clean, opening a PR is one sentence:

create a pr

Claude Code pushes the branch (if you allow it), runs gh pr create, and drafts the title and body from the branch's commits - including a change summary and a checklist if the repo has a PR template. You can be more specific: "open the PR against the develop branch and spell out the tests I ran".

A neat tip from the Anthropic docs: a PR created with gh pr create is automatically linked to the Claude Code session that produced it. Later, when you review it again, you reopen that exact session context with:

claude --from-pr 1234

Very handy when a reviewer leaves comments and you want Claude Code to keep working on them while remembering the full original context.

If you need deeper GitHub operations at this step - reading issues, commenting, managing review requests inside the session - combine GitHub MCP with Claude Code instead of relying on gh alone. MCP lets Claude Code "see" the full GitHub context, not just run CLI commands.

Standardize with CLAUDE.md and a /commit slash command

Plain-language instructions are fast, but if you have to repeat "conventional commits, do not push, no AI signature" every time, turn it into a fixed rule. Drop the following block into a CLAUDE.md file at the repo root - Claude Code reads it every session:

## Git Rules
- Commit using Conventional Commits: type(scope): description (present tense).
- Types to use: feat, fix, docs, refactor, chore, test.
- Split a mixed diff into atomic commits by type/scope.
- Scan for secrets (API keys, tokens, .env) before every commit.
- Do NOT run git push on your own; push only when I explicitly ask.
- Do NOT add a Co-Authored-By line or any AI signature to commit messages.
- Scope names follow the repo's module/folder names.

To understand how to write this file well, see the guide to writing git rules in CLAUDE.md. The next step is to wrap the whole process in a custom slash command so the whole team runs the exact same flow with one command. Create the file .claude/commands/commit.md:

---
description: Conventional commit, atomic split, secret scan
---
Review git status and git diff. Scan the staged files for secrets.
Split the changes into atomic commits by type/scope.
Commit using Conventional Commits. Do NOT push.

From then on, the whole team just types /commit and gets identical behavior - no more off-standard commits. This is exactly how you turn a "personal trick" into a "team standard".

Advanced workflow: worktrees, PR review, and CI

Once you are comfortable, a few techniques push productivity to another level:

Parallel worktrees. To have Claude Code build a feature on its own branch without disturbing your main working directory, use a worktree:

claude --worktree feature-auth

You can run one session fixing a bug and another building a feature in parallel across two worktrees, without stepping on each other.

Pipe into pre-commit/CI. Claude Code runs non-interactively with -p, so you can drop it into a script. For example, summarize recent commits for a changelog or a review step:

git log --oneline -20 | claude -p "summarize these recent commits into a changelog"

Stacked PRs. When a large feature splits into several dependent PRs (PR B builds on the not-yet-merged PR A), you can have Claude Code build the stacked branch chain and open the PRs in the correct parent-child order. This lets reviewers approve small pieces instead of one giant PR, and it is exactly where a ready-made git skill saves a lot of repetitive work.

Self-review the PR before merging. Before you hit merge, let Claude Code read the diff and hunt for logic bugs, edge cases, or vulnerabilities - see how to have Claude review a PR before merge. Combined with your repo's CI, you get two layers of checking: the machine runs tests, the AI reads the meaning of the change. Keep the roles distinct: an agent does a solid first-pass review, but the final merge decision should still have human eyes on it, especially for changes that touch security or data.

Speed up git with a ready-made skill (AgentKit's ak-git)

This whole article basically teaches you to build it yourself: write the prompts, set the CLAUDE.md rules, create the slash command. That approach is perfectly fine and free. But if you would rather not assemble each piece by hand, there is a ready-made git skill called ak-git that does exactly the four things in this article - conventional commits, auto-split by type/scope, secret scanning, and stacked PRs - in a single call.

One line to disambiguate: ak-git is part of AgentKit - the kit for Claude Code at agentkit.best (the ak CLI), which is different from OpenAI's "AgentKit". Do not mix the two up.

ak-git comes from the Engineer Kit ($99, the site does not mention any recurring fee) - if you want to know what else is inside, read the Engineer Kit review before deciding. The honest point: you are not required to buy anything to run this git workflow - everything in this article works with plain Claude Code. The value of the kit is saving the setup effort and keeping behavior consistent across a team.

Common mistakes and safety tips

Letting an agent handle git is convenient, but there are a few familiar traps. Here is what tends to break and how to handle it:

An honest limitation to remember: Claude Code does not "understand" your business logic as deeply as you do, so its messages sometimes describe what changed better than why. For important commits, add the "why" yourself. And always review the diff before approving - the agent is fast, but responsibility for the history is still yours.

Frequently asked questions (FAQ)

Does Claude Code push to the remote on its own?

No, not unless you ask. Every git write command goes through the Bash tool's permission layer, and Claude Code will not push unless you say so. To be safe, add a "do NOT git push on your own" rule to CLAUDE.md.

Do I have to install the gh CLI?

Not for committing - git alone is enough. But for Claude Code to open a pull request itself with gh pr create, you need gh installed and logged in via gh auth login.

Does the commit include a "Generated with Claude" line, and how do I turn it off?

By default there is usually a Co-Authored-By line crediting Claude. To turn it off, add a rule to CLAUDE.md: "do not add a Co-Authored-By line or any AI signature to commit messages". Claude Code will drop it.

How do I get Claude to split a pile of changes into multiple commits?

Give the instruction "split these changes into atomic commits by type/scope". Claude Code groups the diff by topic, stages each group, then creates a separate commit per type of change.

Can it open a private (draft) pull request?

Yes. Say "create the PR as a draft" and Claude Code adds the matching flag when it runs gh pr create. You can also specify the target branch and reviewers.

Does it work with GitLab or Bitbucket?

The conventional commits, commit splitting, and secret scanning work with any git repo. Only the automatic PR step relies on gh, which is tied to GitHub; for GitLab/Bitbucket use the matching CLI (such as glab) or do it manually.

Conclusion and next steps

The git workflow with Claude Code boils down to four steps: set up git plus gh, write proper conventional commits, split into atomic commits and scan for secrets, then open the PR with gh. Put the rules in CLAUDE.md and a /commit slash command and the whole team shares one standard. Next: wire in GitHub MCP for deeper GitHub operations, and let Claude review the PR before merge. If you would rather skip the build-it-yourself part, the AgentKit bundle — now $149 (from $198) ships the ak-git skill that runs exactly this workflow.