Git Workflows & Code Review

Git is the backbone of modern software development, but it is also one of the most error-prone parts of the workflow. A force push to the wrong branch can destroy days of work. A poorly written commit message makes debugging impossible three months later. A missed security vulnerability in a pull request can reach production. Claude Code transforms git from a source of anxiety into a structured, safe, and expressive part of your development process.

This lesson covers the full git lifecycle with Claude Code: from committing changes and managing branches to opening pull requests and reviewing code. Every pattern here reflects how Claude Code actually operates under the hood, including the safety constraints that prevent catastrophic mistakes.

The Git Safety Protocol

Before diving into workflows, you need to understand the safety guarantees Claude Code enforces when working with git. These are not suggestions. They are hard constraints built into how Claude operates.

Claude Code will NEVER run destructive git commands unless you explicitly request them. This includes:

• git push --force (can overwrite remote history)
• git reset --hard (discards all uncommitted changes)
• git checkout . or git restore . (reverts all working tree changes)
• git clean -f (deletes untracked files permanently)
• git branch -D (force-deletes a branch regardless of merge status)

Beyond avoiding destruction, Claude Code follows additional safety principles:

• Always creates NEW commits rather than amending previous ones. When a pre-commit hook fails, the commit did not happen, so --amend would modify the wrong commit. Claude stages fixes and creates a fresh commit instead.
• Prefers staging specific files by name over git add -A or git add ., which can accidentally include sensitive files like .env, credentials, or large binaries.
• Never skips hooks such as --no-verify or --no-gpg-sign unless you explicitly request it.
• Never force pushes to main/master and will warn you if you ask it to.

This protocol means you can hand Claude Code significant git autonomy without worrying about repository-destroying accidents.

Creating Commits

The commit workflow is one of the most common interactions you will have with Claude Code. Instead of writing commit messages yourself, you describe what you have done (or just say "commit"), and Claude analyzes the actual changes to produce a precise, conventional commit message.

The Commit Workflow Step by Step

When you ask Claude to commit your changes, it follows a structured process:

Here is what this looks like in practice:

> I've fixed the race condition in the WebSocket handler. Commit these changes.

Claude examines the diff, sees that you added a mutex lock around the connection pool access, and produces:

git commit -m "$(cat <<'EOF'
fix: Prevent race condition in WebSocket connection pool
 
Add mutex lock around pool access to prevent concurrent goroutines
from corrupting shared connection state during high-traffic bursts.
 
Co-Authored-By: Claude Code <noreply@anthropic.com>
EOF
)"

Notice how the message explains why the mutex exists (preventing corruption during high-traffic bursts) rather than merely stating what was added (a mutex lock). This distinction makes commit history genuinely useful for future debugging.

Conventional Commit Style

Claude Code follows the conventional commits specification by default, using prefixes that categorize changes:

If your project uses a different convention, add it to your CLAUDE.md file:

# Git Conventions
- Commit messages use Jira ticket prefix: [PROJ-123] Description
- No conventional commit prefixes
- Keep subject line under 50 characters

Claude reads this at session start and adapts its commit messages accordingly.

Creating Pull Requests

Claude Code uses the GitHub CLI (gh) to create pull requests with structured, informative descriptions. The process goes beyond just running gh pr create. Claude inspects the full branch history to produce a meaningful summary.

The Pull Request Workflow

> Create a PR for my changes

Or use the built-in skill:

> /commit-push-pr

Behind the scenes, Claude follows this sequence:

The generated PR follows a consistent structure:

## Summary
- Add rate limiting middleware for all API endpoints
- Configure Redis-backed sliding window counter
- Add bypass for internal health check routes
 
## Test plan
- [ ] Verify rate limit headers appear in API responses
- [ ] Confirm 429 status after exceeding limit
- [ ] Check health endpoint bypasses rate limiting
- [ ] Run load test to validate sliding window behavior

Customizing PR Behavior

Add PR conventions to your CLAUDE.md to ensure consistency across your team:

# PR Conventions
- PR titles use conventional commit format: "feat: Description"
- Always include a "## Breaking Changes" section if applicable
- Link related Jira tickets in the description
- Add "Reviewers: @team-lead" to all PRs

Code Review with --from-pr

One of Claude Code's most powerful git integrations is AI-powered code review. Using the --from-pr flag, Claude reads an entire pull request diff, understands the context of every change, and provides structured feedback.

Reviewing a Pull Request

claude --from-pr https://github.com/org/repo/pull/42

Or using just the PR number when you are inside the repository:

claude --from-pr 42

Claude reads the full diff, checks for common issues, and provides detailed feedback. You can guide the review with a follow-up prompt:

> Focus on security issues and potential breaking changes

What Claude Checks During Review

Claude performs a multi-dimensional analysis when reviewing code:

Using Claude as a CI Reviewer

You can also integrate Claude Code into your CI pipeline for automated review on every pull request:

# In a CI script or package.json
claude -p "Review the changes in this PR. Focus on security, correctness, and performance. Flag anything that should block merge." --from-pr $PR_NUMBER

Branch Management

Claude Code handles the full branch lifecycle through natural language commands.

Creating and Switching Branches

> Create a new feature branch for adding email notifications

Claude creates a descriptively named branch from your current base:

git checkout -b feat/email-notifications

To switch branches:

> Switch to the staging branch

Claude runs git checkout staging, and if you have uncommitted changes, it will warn you before switching and suggest stashing or committing first.

Working with Remote Branches

> Pull the latest changes from main and rebase my branch on top

Claude runs git fetch origin followed by git rebase origin/main, handling the common workflow of keeping a feature branch up to date. If conflicts arise during the rebase, Claude shifts into conflict resolution mode (covered in the next section).

Merge Conflict Resolution

Merge conflicts are one of the most stressful parts of git. Claude Code transforms conflict resolution from a manual, error-prone process into an intelligent, context-aware operation.

How Claude Resolves Conflicts

When a merge or rebase produces conflicts, Claude does not blindly pick one side. It follows a structured approach:

Here is a practical example:

> I tried to rebase on main and got conflicts in three files. Help me resolve them.

Claude reads each conflicted file, explains what both sides changed, proposes a resolution, and applies it. You review each resolution before Claude stages it and continues the rebase.

Git History Analysis

Git history is a powerful debugging and understanding tool, but most developers underuse it because the commands are awkward. Claude Code makes history analysis conversational.

Understanding Code Evolution

> Why was the retry logic in api-client.ts changed last month?

Claude runs git log --oneline -20 -- src/api-client.ts to find relevant commits, then uses git show <hash> to read the full diffs and commit messages. It synthesizes this into a narrative explanation of how and why the code evolved.

Debugging with Git Bisect

> The dashboard started showing incorrect totals sometime in the last two weeks. Help me find which commit broke it.

Claude can guide a git bisect session, helping you define the good and bad commits, then systematically testing midpoints to isolate the exact commit that introduced the regression.

Blame Analysis

> Who last modified the pricing calculation logic and why?

Claude runs git blame on the relevant file, identifies the author and commit, then reads the commit message and surrounding changes to explain the reasoning behind the modification.