Git Workflow Integration

Stop writing "fix stuff" commits. Let Claude generate meaningful messages:

After making changes:

> Look at my staged changes and write a commit message

Claude will:

1. Run git diff --staged
2. Analyse what changed and why
3. Write a conventional commit message

Example output:

feat(auth): add password reset flow with email verification

- Add POST /api/auth/reset-password endpoint
- Create email template for reset links
- Add token expiry validation (1 hour)
- Update User model with resetToken field

Customise the style:

> Write a commit message for these changes. Use conventional 
> commits format (type: description). Keep it under 72 characters 
> for the subject line.

Commit directly:

> Stage all changes and commit with an appropriate message

Claude will stage, generate the message, and ask you to approve before committing.

Claude can generate comprehensive PR descriptions by analysing the branch diff:

> Create a PR description for the current branch. Compare against main.
> Include: summary, changes made, testing instructions, and any notes for reviewers.

Example output:

## Summary
Adds a complete password reset flow with email verification.

## Changes
- New endpoint: POST /api/auth/reset-password
- New endpoint: POST /api/auth/confirm-reset
- New email template: password-reset.html
- Updated User model with resetToken and resetTokenExpiry fields
- Added rate limiting (3 requests per email per hour)

## Testing
1. Go to /login and click "Forgot password?"
2. Enter a valid email
3. Check email for reset link (or check logs in dev)
4. Click link, set new password
5. Verify login works with new password

## Notes for Reviewers
- The rate limiting uses our existing RateLimiter middleware
- Token expiry is set to 1 hour (configurable via env var)
- I chose bcrypt for token hashing to match our existing password hashing

Create the PR directly:

> Create a pull request on GitHub for this branch against main

Claude will use the gh CLI to create the PR with the generated description.

Merge conflicts are where Claude truly shines — it can understand both sides:

> I have merge conflicts after rebasing onto main. Help me resolve them.

Claude will:

1. Find files with conflicts (git diff --name-only --diff-filter=U)
2. Read the conflicted sections
3. Understand both versions (yours and theirs)
4. Propose a resolution that preserves both intents

For complex conflicts:

> There's a conflict in src/api/users.ts. My branch added validation 
> and main refactored the response format. I need both changes.

Claude will merge the logic from both sides into a coherent resolution.

For mechanical conflicts (imports, etc.):

> Resolve all the import conflicts — keep both sets of imports, 
> remove duplicates

Verify after resolving:

> All conflicts are resolved. Run the tests to make sure nothing broke.

Use Claude to review code before submitting — or to help review others' PRs:

Self-review before PR:

> Review my changes on this branch compared to main. Look for:
> - Bugs or logic errors
> - Security issues
> - Missing error handling
> - Inconsistency with project patterns

Reviewing someone else's PR:

> Review the changes in PR #42. What potential issues do you see?

(Requires GitHub CLI or copy-pasting the diff)

Focused review:

> Review just the database migration in this PR. 
> Is it safe to run on a production database with existing data? 
> Will it lock tables?

Getting a second opinion:

> I'm about to merge this. Anything that could break in production 
> that I might have missed?

Claude can help with branch strategy and cleanup:

Creating feature branches:

> Create a new branch for adding user notifications. 
> Name it following our convention (feature/short-description).

Understanding branch state:

> What's the current state of this branch? How far ahead/behind 
> main am I? What commits are unique to this branch?

Cleaning up:

> Show me all local branches that have been merged into main 
> and can be safely deleted.

Stashing work:

> I need to switch branches but I have uncommitted changes. 
> Stash them with a descriptive message about what I was working on.

Cherry-picking:

> I need commit abc123 from the feature/payments branch applied 
> to this branch. Cherry-pick it and resolve any conflicts.

Patterns that work well with Claude and git:

Checkpoint commits before AI work:

> Commit everything as-is with message "checkpoint: before AI refactor"

Atomic commits after AI generates: Instead of one giant commit for all AI-generated changes, split logically:

> Stage and commit just the type definitions (src/types/)
> Then stage and commit just the API changes (src/api/)
> Then stage and commit just the frontend changes (src/components/)

Interactive staging:

> Stage only the changes related to the validation logic, not the 
> formatting changes. I want two separate commits.

Commit message conventions in CLAUDE.md:

## Git Conventions
- Use conventional commits: type(scope): description
- Types: feat, fix, refactor, docs, test, chore, perf
- Keep subject under 72 characters
- Body should explain WHY, not WHAT (the diff shows the what)