Claude Code in Git, CI, code review and refactoring

1.Branches, commits and pull requests with Claude Code

Claude Code fits into version control the same way a developer does: plan the change, make it with tests, then commit and open a pull request. The order matters. Asking first which files need to change and what the flow is produces a plan you can correct before any code exists. The implementation prompt then points back to that plan and asks for tests, a test-suite run, and fixes for any failures. Only then does Claude commit with a descriptive message and open the PR.

Parallel work needs separate checkouts. Worktrees let you run separate CLI sessions in isolated git checkouts, so two sessions editing the same repository don't overwrite each other. The same isolation supports a writer and reviewer split. One session implements a rate limiter, and a second session with a fresh context reviews @src/middleware/rateLimiter.ts for edge cases and race conditions. Its findings then go back to the first session to fix.

Sources1

2.Running Claude Code in GitHub Actions

In CI, Claude Code runs without a terminal. It is the same non-interactive mode described in [Headless mode (claude -p) and streaming output](lesson:3.1), packaged as the anthropics/claude-code-action GitHub Action. The quickest setup is to run /install-github-app from Claude Code. That installs the Claude GitHub App, adds the authentication secret and opens a pull request with the workflow file. The secret is either ANTHROPIC_API_KEY from the Console or CLAUDE_CODE_OAUTH_TOKEN, which authenticates with a Claude subscription. For an organization, install the app once at the org level and store the secret as an organization-level Actions secret.

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Each line has a job. actions/checkout gives Claude a copy of the repository to work in. actions: read lets it read CI results on the PR. The if: stops runners from starting on comments that don't mention @claude. Whether a prompt input is set decides how the action behaves. Without one, it runs in interactive mode: it waits for the trigger phrase and replies as a comment on the issue or PR. With one, it runs in automation mode and starts without a mention. Results then go to the workflow run log unless the prompt tells Claude to post and it has a tool that can.

Two guards limit who can start a run. On issue and PR events, the triggering user needs write access to the repository. On every event, bot actors are rejected unless listed in allowed_bots, so one bot's comment can't keep triggering Claude in a loop. Scheduled runs are attributed to a repository user. If that user is a bot, it has to be listed as well.

Sources2

3.Automated pull request review that stays actionable

There are two ways to get Claude reviewing every PR. Managed Code Review is set up from Claude Code admin settings with the Claude GitHub App, and needs no workflow file. It runs a multi-agent analysis and marks each finding 🔴 Important (fix before merging), 🟡 Nit (minor, not blocking) or 🟣 Pre-existing (a bug the PR didn't introduce). Alternatively, you write your own workflow that runs the code-review plugin through the GitHub Action.

When a review runs drives both noise and cost. Each repository picks a trigger, and anyone with write access can also request a review from a top-level PR comment.

Reviews stay focused because you tell the reviewer what matters. CLAUDE.md is general project context, and Code Review flags newly introduced violations of it as nits. REVIEW.md holds review-only rules: what to flag, at what severity, and how findings are reported. A good REVIEW.md saves Important for findings that would break behavior or leak data, caps the number of nits, and excludes anything CI already enforces.

## Cap the nits

Report at most five Nits per review. If you found more, say "plus N
similar items" in the summary instead of posting them inline. If
everything you found is a Nit, lead the summary with "No blocking
issues."

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

In a self-built review workflow, the step that most often goes missing is posting. Without --comment, the plugin writes its findings only to the workflow run log, and the PR shows nothing.

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review  ?  ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Sources3

4.Refactoring in small steps and migrating in batches

A small refactor or fix is safe when each step is checked against a test. For a bug, have Claude write a failing test that reproduces it, then fix the code until the test passes. For a change with a plan, a subagent can review the diff against PLAN.md. It checks that every requirement is implemented and that nothing outside the task's scope changed, and reports gaps rather than style preferences. Keep the scope tight: a refactor that wanders into unrelated files is harder to review than two separate PRs.

A large migration is a different problem. Too many files for one session, but each file is a similar, independent task. The pattern is to generate a task list, write a script that runs headless Claude once per file, test the script on a few files, and only then run it on all of them. Narrow --allowedTools to editing and git commit, so each file becomes its own commit and nothing else is allowed. Asking for OK or FAIL gives the loop a result it can check. When batches run at the same time, give each its own worktree.

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

The trial run exists to fix the instructions, not to make progress. In one Anthropic migration, translating three files first exposed two critical issues that would otherwise have spread across all 1,448 files. Those trial outputs were then thrown away. After that, each batch goes through the same loop: implement, review, fix.

Sources14

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Adding the code-review plugin to a workflow is enough for findings to appear on the PR.Why is that wrong?

   Without --comment, Claude posts nothing to the PR, and the findings exist only in the workflow run log.

   Covered in Automated pull request review that stays actionable

2. 2.Choosing "After every push" costs the same as reviewing once, just with fresher results.Why is that wrong?

   Every push triggers a full review, so cost scales with the number of pushes to the PR.

   Covered in Automated pull request review that stays actionable

3. 3.Another bot, such as a dependency updater, can trigger the Claude action just by mentioning @claude.Why is that wrong?

   The action rejects bot actors on every event unless they are listed in allowed_bots, which prevents trigger loops.

   Covered in Running Claude Code in GitHub Actions

Practise it for real

Add an automated Claude review to a repository you control and see it comment on a pull request

1. 1.Run /install-github-app from Claude Code in the repository and finish the setup it opens

   Why: It installs the Claude GitHub App, adds the authentication secret and prepares the workflow PR in one step

   You should see: A pull request adding the Claude workflow file, and an ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN secret on the repository

2. 2.Add a review workflow on pull_request events that runs the code-review plugin with --comment and allows the inline-comment tool

   Why: --comment is what makes findings appear on the PR instead of only in the run log

   You should see: A new workflow listed under the repository's Actions tab

3. 3.Open a small PR that introduces an obvious bug, such as an off-by-one in a loop

   Why: A deliberate defect shows whether the review flags real problems

   You should see: An inline comment on the faulty line, or one summary comment if Claude finds nothing

4. 4.Remove --comment from the prompt, push again and open the workflow run log

   Why: Shows where findings go when posting is turned off

   You should see: No new PR comments, with the findings visible in the run log