Commits, Branches, and Pull Requests

Twenty minutes of pair-programming with Claude Code. Feature works. Now comes the git ceremony: commit, branch, maybe a PR. You could handle all that yourself, but why? Let Claude Code deal with it while you stay focused on the actual work.

The real skill is knowing when to let it drive and when to grab the wheel.

Commits That Actually Say Something

Claude Code doesn't write git commit -m "update files". It reads the diff, understands what changed, and writes a message that captures intent. Not just what, but why.

# Just ask naturally
> commit these changes
 
# Or be more specific
> commit with a message explaining the auth refactor

It stages the relevant files, reads the diff, and produces something like "refactor auth middleware to validate JWT claims before route matching." Future-you will appreciate that when reading git log six months from now.

Want conventional commits? Just say so:

> commit using conventional commit format

Out comes fix(auth): validate JWT claims before route matching. No remembering prefixes.

But the best approach is putting your conventions in CLAUDE.md once and forgetting about it:

## Git Conventions
- Use conventional commits: type(scope): description
- Types: feat, fix, refactor, docs, test, chore
- Keep the subject line under 72 characters
- Write in imperative mood ("add" not "added")

Done. Every commit follows the rules without you repeating yourself.

Branches

Dead simple. Just ask.

> create a branch for adding rate limiting to the API

Claude Code runs git checkout -b feature/api-rate-limiting. Done. If you have naming conventions (and you should), put them in CLAUDE.md:

## Branch Naming
- Features: feature/short-description
- Bugs: fix/issue-number-description
- Chores: chore/short-description

No more "wait, do we use slashes or dashes?" moments.

You can also combine branch creation with actual work: "create a branch called feature/user-avatars and add avatar upload support to the profile page." One prompt, two steps. Claude Code creates the branch and starts building.

Pull Requests

PRs are where Claude Code really pulls its weight. It uses gh CLI under the hood, so you need GitHub CLI installed and authenticated. After that, PRs become a conversation.

Simplest version:

> create a pr for my changes

Claude Code pushes your branch, opens a PR, writes a title and description from your commits and diffs. But I strongly recommend the step-by-step approach instead:

# Step 1: Get a summary first
> summarize the changes I've made to the authentication module
 
# Step 2: Once you're happy with the summary
> create a pr
 
# Step 3: Polish the description
> enhance the PR description with more context about the security improvements

You get to review what Claude Code thinks the changes are before it writes the PR description. Way better than fire-and-forget.

When you create a PR with gh pr create, the session links to it automatically. Come back later with:

claude --from-pr 42

Full context. Description. Review comments. All there.

Try it

Pick something small. A README update, a typo fix. Run the full flow:

> create a branch called fix/readme-typos
> fix the typos in README.md
> commit these changes
> create a pr

Check the commit message. Read the PR description. Calibrate your trust before using this on real features.

Guardrails

Powerful doesn't mean reckless. Guardrails matter here.

In default permission mode, Claude Code asks before running state-changing git commands. You see the exact git commit or git push before it executes. Review the message, check the staged files, approve or reject. That's your safety net.

In permissive mode, it might commit and push without asking. Fine for low-risk work. Dangerous otherwise. A bad push to main is harder to undo than to prevent.

Always check before pushing. Even if you let Claude Code write commits freely, scan git log --oneline before push. Five seconds. Catches problems early.

CLAUDE.md is your best guardrail. Put your conventions there. Branch naming, commit format, PR template. Claude Code follows them consistently when it knows them. Repository etiquette belongs in a config file, not in your head.

## PR Conventions
- Always create PRs against the `develop` branch
- Include a "Test Plan" section in PR descriptions
- Tag PRs with relevant labels (bug, feature, etc.)
- Request review from at least one team member

Never let Claude Code rewrite history. No interactive rebases. No force pushes. Those are destructive operations that deserve your full attention. Let it handle the creative work (messages, descriptions, branch management). Keep the dangerous stuff manual.

What Matters

• Commit messages come from actual diffs, capturing "why" not just "what"
• CLAUDE.md conventions mean you never repeat yourself about format rules
• Step-by-step PR flow (summarize, create, enhance) beats fire-and-forget every time
• --from-pr resumes sessions with full PR context
• Review before push. Always.