Git Integration & Team Workflows

Git Integration & Team Workflows

Claude Code has deep integration with Git, making it a powerful tool for version control workflows. However, this power comes with responsibility — Claude Code includes built-in safety mechanisms to prevent destructive Git operations. Understanding these safety features, plan mode, and team workflow patterns is essential for the CCA-F exam.

Git Safety Mechanisms

Claude Code implements a Git safety protocol that prevents common mistakes and destructive operations. These protections are always active and cannot be overridden by CLAUDE.md or settings:

Default Git Protections

• Never force pushes: Claude Code will not rungit push --force unless explicitly instructed by the user. Even when instructed, it will warn before pushing force to main/master.
• Never skips hooks: Claude Code will not use --no-verifyto bypass pre-commit or other Git hooks unless the user explicitly requests it.
• Prefers new commits over amending: When making changes, Claude Code creates new commits rather than amending existing ones. This preserves Git history and avoids data loss.
• Avoids destructive operations: Commands like git reset --hard,git checkout ., git clean -f, and git branch -Dare avoided unless explicitly requested.
• Never modifies git config: Claude Code will not change your Git configuration.

# Claude Code Git Safety Protocol:
# - NEVER force push (especially to main/master)
# - NEVER skip hooks (--no-verify)
# - NEVER amend commits without explicit instruction
# - NEVER run destructive commands (reset --hard, clean -f)
# - NEVER modify git config
# - ALWAYS prefer creating new commits
# - ALWAYS warn before destructive operations

Commit Workflow

When asked to create a commit, Claude Code follows a structured process:

1. Check status: Run git status and git diffto understand what has changed.
2. Review history: Check recent commit messages with git logto match the repository's commit message style.
3. Stage selectively: Add specific files by name rather than usinggit add -A or git add ., which could include sensitive or unintended files.
4. Craft message: Write a concise commit message that summarizes the "why" rather than the "what."
5. Verify success: Run git status after committing to confirm the commit was created successfully.

# Claude Code commit workflow example:

# Step 1: Check status
git status
git diff

# Step 2: Check commit style
git log --oneline -10

# Step 3: Stage specific files (not git add -A)
git add src/auth/login.ts src/auth/login.test.ts

# Step 4: Create commit with descriptive message
git commit -m "Fix session expiration not respecting timezone offset

The session TTL calculation was using UTC midnight instead of the
user local timezone, causing premature logouts for users west of UTC.

Co-Authored-By: Claude <noreply@anthropic.com>"

# Step 5: Verify
git status

Pre-Commit Hook Failures

When a pre-commit hook fails, Claude Code follows a specific recovery pattern:

1. The commit fails due to the hook (the commit was NOT created).
2. Claude Code examines the hook output to understand the failure.
3. Claude fixes the issue (e.g., formatting, lint errors).
4. Claude re-stages the fixed files.
5. Claude creates a new commit (NOT --amend, since the previous commit does not exist).

Plan Mode

Plan mode is a feature that allows you to ask Claude to describe its intended approach before making any changes. This is especially valuable for large refactors, architectural changes, or any task where you want to review the strategy first.

# Ask Claude to plan before executing
# In interactive mode:
"Plan how you would refactor the authentication module to use JWT
instead of session cookies. Do not make any changes yet."

# Claude responds with a detailed plan:
# 1. Create new JWT utility in src/lib/jwt.ts
# 2. Update auth middleware to validate JWT tokens
# 3. Modify login endpoint to issue JWT instead of session cookie
# 4. Update logout to invalidate JWT
# 5. Migrate existing session tests to JWT tests
# 6. Update API documentation

# After reviewing, you can approve:
"Go ahead with the plan, but skip step 6 for now."

Plan mode works by instructing Claude to use only read-only tools during the planning phase. It can read files and search the codebase to inform its plan but will not make edits until you approve.

When to Use Plan Mode

• Large refactors that touch many files
• Architectural changes with many downstream effects
• Unfamiliar codebases where you want to understand the approach first
• Tasks where the correct approach is ambiguous
• Team settings where plans need review before execution

Team Workflow Configurations

Setting up Claude Code for a team requires coordination across CLAUDE.md, settings, and slash commands. Here is a complete team configuration example:

Repository Structure

my-team-project/
  CLAUDE.md                     # Project conventions
  .claude/
    settings.json               # Shared permissions and MCP servers
    commands/
      review.md                 # /project:review
      fix-lint.md               # /project:fix-lint
      new-feature.md            # /project:new-feature
      pre-merge.md              # /project:pre-merge
  .claudeignore                 # Files to ignore
  .github/
    workflows/
      claude-review.yml         # Automated PR review
      claude-fix.yml            # Automated fix on label

Team CLAUDE.md

# CLAUDE.md

# Team Project: Payment Processing Service

## Team Conventions
- All PRs require Claude Code review before merge
- Use conventional commits: feat:, fix:, refactor:, test:, docs:
- All new endpoints require OpenAPI documentation
- Database changes require a migration and a rollback script

## Architecture
- Express.js REST API in /src/api/
- PostgreSQL with Knex.js query builder
- Redis for caching (cache-aside pattern)
- Stripe SDK for payment processing

## Build & Test
- Install: npm ci
- Build: npm run build
- Test all: npm test
- Test single: npm test -- --grep "test name"
- Lint: npm run lint
- Type check: npx tsc --noEmit

## Security Rules
- NEVER log credit card numbers or PII
- All Stripe API calls must go through /src/lib/stripe-client.ts
- Input validation required on all API endpoints (use Joi schemas)
- SQL injection prevention: always use parameterized queries via Knex

## Code Review Checklist
- Tests for new functionality
- Error handling for all async operations
- Input validation on API endpoints
- No hardcoded secrets or credentials
- Database migrations are reversible

Team Settings

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm ci)",
      "Bash(npm test *)",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(npx tsc --noEmit)",
      "Bash(npx knex migrate:latest)",
      "Bash(npx knex migrate:rollback)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git checkout -b *)",
      "Bash(git branch *)",
      "Bash(git stash *)"
    ],
    "deny": [
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(git clean *)",
      "Bash(rm -rf *)",
      "Bash(npm publish *)",
      "Bash(npx knex migrate:rollback --all)"
    ]
  },
  "mcpServers": {
    "dev-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${DEV_DATABASE_URL}"
      }
    }
  }
}

Team Slash Commands

# .claude/commands/pre-merge.md

Perform a pre-merge review of the current branch:

1. Run the full test suite: npm test
2. Run type checking: npx tsc --noEmit
3. Run linting: npm run lint
4. Check for any TODO or FIXME comments in changed files
5. Verify all new files have appropriate test coverage
6. Check that any database migrations have rollback scripts
7. Ensure no hardcoded secrets or credentials

Report any issues found. If all checks pass, confirm the branch
is ready for merge.

# .claude/commands/new-feature.md

Create a new feature branch and scaffold for:

$ARGUMENTS

Steps:
1. Create a feature branch: git checkout -b feat/$ARGUMENTS
2. Create the necessary source files following our project structure
3. Create corresponding test files
4. Add input validation schemas if API endpoints are involved
5. Create a database migration if schema changes are needed
6. Run tests to ensure nothing is broken
7. Make an initial commit with the scaffolding

Branching Strategies with Claude Code

Claude Code works well with standard Git branching strategies:

• Feature branches: Claude creates feature branches for new work, keeping main clean. Use: "Create a feature branch for the payment retry logic."
• Fix branches: For bug fixes triggered by CI/CD or issue labels. Use:"Fix the auth bug on a new branch and create a PR."
• Worktrees: Claude Code supports Git worktrees for working on multiple branches simultaneously without switching. This is useful for parallel tasks.

# Working with branches in Claude Code

# Create and switch to a new branch
"Create a branch called feat/retry-payments and implement the retry logic"

# Work on a fix branch
"Check out a new branch fix/auth-timeout and fix the session timeout bug"

# Use worktrees for parallel work
"Create a worktree for the database migration while I continue on main"

Pull Request Workflows

Claude Code can create pull requests as part of its workflow, using the GitHub CLI (gh):

# Claude Code PR creation workflow:
# 1. Checks git status and diff
# 2. Reviews all commits on the branch
# 3. Pushes to remote with -u flag
# 4. Creates PR with gh pr create

# Example PR creation by Claude Code:
gh pr create \
  --title "feat: add payment retry logic" \
  --body "## Summary
- Added retry mechanism for failed payments
- Configurable retry count and backoff strategy
- Added comprehensive test coverage

## Test plan
- [x] Unit tests for retry logic
- [x] Integration tests with mock Stripe API
- [ ] Manual testing with staging environment"

Handling Merge Conflicts

Claude Code can help resolve merge conflicts by understanding both sides of the conflict and the intent behind each change:

# Ask Claude to help with merge conflicts
"I have merge conflicts after rebasing on main. Help me resolve them
by keeping the intent of both changes where possible."

# Claude will:
# 1. Read the conflicted files
# 2. Understand the changes from both branches
# 3. Resolve conflicts preserving both intents
# 4. Run tests to verify the resolution
# 5. Create a commit with the resolution

Multi-Developer Coordination

When multiple team members use Claude Code on the same repository, coordination is important:

• Shared CLAUDE.md: Ensures all developers' Claude Code instances follow the same conventions.
• Shared settings.json: Ensures consistent permissions and tool access.
• Shared slash commands: Provides a common set of workflows.
• Personal overrides: Each developer can customize via~/.claude/CLAUDE.md and .claude/settings.local.json.

# Team onboarding checklist for Claude Code:
# 1. Clone the repo (CLAUDE.md and .claude/ come with it)
# 2. Set up personal ~/.claude/CLAUDE.md with preferences
# 3. Create .claude/settings.local.json for personal overrides
# 4. Set up environment variables for MCP server connections
# 5. Run /project:review on a test PR to verify setup

Audit and Compliance

For teams with compliance requirements, Claude Code supports several audit mechanisms:

• Co-authored commits: Claude Code adds a Co-Authored-Bytrailer to commits, making it clear which commits involved AI assistance.
• Session history: All Claude Code sessions are logged locally, providing an audit trail of what actions were taken.
• Permission logging: The settings system provides a record of what tools are allowed and denied, establishing a security baseline.

# Example commit with Co-Authored-By trailer:
git log -1
# commit abc123
# Author: Developer Name <dev@example.com>
# Date: Mon Jan 15 10:30:00 2025 -0800
#
#     feat: add payment retry logic
#
#     Implemented exponential backoff retry for failed Stripe charges.
#     Maximum 3 retries with 1s, 2s, 4s delays.
#
#     Co-Authored-By: Claude <noreply@anthropic.com>

Exam-Relevant Concepts Summary

• Git safety: no force push, no --no-verify, no amend (unless asked), no destructive ops.
• Pre-commit hook failure: fix the issue and create a NEW commit (never amend).
• Selective staging: git add specific-file over git add -A.
• Plan mode: Claude reads and plans but does not edit until approved.
• Team config: CLAUDE.md + settings.json + commands/ are shared; settings.local.json is personal.
• Co-Authored-By trailers provide audit trail for AI-assisted commits.
• Worktrees enable parallel branch work without context switching.
• Claude Code uses gh CLI for GitHub operations (PRs, issues).