Git Baseline — Claude Code Guide

A safe start begins before the prompt

Claude Code works with a live repository, so the first check is not the task wording but the state of the workspace. Make sure the correct directory is open, local changes are understood, and there is a separate point of return for new work.

A Git baseline is a recorded state that you can compare Claude’s result against. The repository does not have to be completely clean, but you must be able to explain every existing diff before starting a new task.

Baseline sequence

1. Check the path to the current directory.
2. Run git status and understand every modified, deleted, or untracked file.
3. Create a separate branch for the new task if the project process allows it.
4. Check .gitignore rules and the actual contents of the workspace.
5. Write down the allowed and forbidden parts of the task.
6. Only then start Claude Code and provide it with context.

pwd
git status
git switch -c fix/refund-inbox-order
git check-ignore -v .env

What to do with an unclear diff

Do not silently mix existing local changes with a new task. First investigate the specific file or range, determine where the changes came from, and only then decide whether to finish, commit, temporarily set aside, or discard them.

A separate branch does not automatically fix a conceptual mistake. It only makes the experiment boundary visible and lets you return to the previous state.

git diff src/support/refund/RefundInboxService.java
git diff
git status

A short scope before starting Claude

• Name a specific goal instead of saying “improve the module.”
• Specify the allowed directories or files.
• List areas that cannot be changed without a separate decision.
• Define in advance how you will verify the result.

Task: check the order of refund requests in the inbox.
Allowed changes: src/support/refund/** and related tests.
Forbidden changes: API contracts, database migrations, .env* files, and environment configuration.

Control after Claude’s work

1. Review the complete git diff and the number of changed files.
2. Compare the actual change area with the initial scope.
3. Run relevant tests, lint, or build checks.
4. Check the key scenario manually if automated checks are insufficient.
5. If the iteration failed, first determine exactly what should be kept or rolled back.

git diff
git restore src/support/refund/RefundInboxService.java
git status