Create a git baseline before Claude Code edits files, then read the actual changes with `git status` and `git diff`. You can ask AI to explain the diff, but do not rely on the explanation alone: review the diff and execution results yourself, then stage and commit the changes directly.
Who this is forBeginners who want to learn a minimal git workflow for leaving a recoverable baseline and review record for changes made with Claude Code
Claude Code creates automatic checkpoints for each prompt and provides options to rewind code or conversation with `/rewind`, but the official documentation also explains that this does not replace version control such as git. In particular, files changed by Bash commands such as rm, mv, and cp, and files edited directly outside Claude Code, may not be tracked or restored by checkpoints. For important work, keep a git baseline separately from AI features.
| Tool | Role in this article | Caution |
|---|---|---|
| Claude Code checkpoint | Assist with rewinding during a session | Not version control that tracks every external change |
| git commit | Record explicit states before and after work | A person must check which files are committed |
| git diff | Inspect actual line-by-line changes | The raw diff is the reference, not the AI explanation |
| Execution result | Verify that the feature works as required | Functional verification is still needed even if the diff is small |
The goal of this article is not to learn every git feature. We will use only a minimal flow: commit the pre-work state, read the diff after the AI changes something, verify execution results, and then commit.
If the folder is already a git repository, check the current state first. If it is not, you can initialize one in the practice folder. The following example records the files from the previous articles as the pre-work baseline. In a real project, do not blindly add every file; use `git status` to confirm what should be included.
cd vibe-expenses
git init
git status --short
git add expenses.csv summarize.py CLAUDE.md
git diff --cached
git commit -m "Baseline before category summary"If this is the first commit on this computer, git commit may stop because author information has not been configured. In that case, set it once with git config --global user.name "Name" and git config --global user.email "Email", then run the commit again. If you plan to publish the repository, use an email address you are comfortable making public.
`git diff --cached` shows the staged changes that will go into the commit. The first commit can produce a long diff, but at minimum check that no unintended files are included. In a real work repository, do not accidentally add sensitive files such as `.env`, key files, or personal data. This series uses only synthetic data from the outset.
This task is one feature: add the `--by-category` option to summarize.py. Narrow the request to Claude Code as well, telling it not to combine unrelated refactoring or file cleanup. The smaller the change, the easier the diff is to read and the easier it is to identify the cause if something goes wrong.
Add the `--by-category` option only to summarize.py.
Do not change the default execution result, and do not modify expenses.csv or CLAUDE.md.
Do not add external packages.
After the edit, tell me which files you changed.The Claude Code documentation notes that you can ask in natural language which files changed, for example, 'what files have I changed?'. However, do not use the AI's answer alone to determine the change scope. In the next step, verify the actual state reported by git.
After the work is complete, first run `git status --short` to see which files changed. If the request was followed, only summarize.py should be modified. Then run `git diff -- summarize.py` to read the actual uncommitted changes. If you check only the filename and commit immediately, you can miss an incorrect line changed by the AI.
git status --short
git diff -- summarize.pyHere, git diff is the evidence of what actually changed, while the AI explanation is only an aid for understanding that evidence. If they disagree, use the raw diff and the actual file as the basis for your judgment.
If the diff is unfamiliar, you can ask Claude Code to explain the current changes. Do not ask for new edits at the same time; requesting explanation only keeps review separate from additional modification.
Read the current git diff and explain what changed in summarize.py.
Organize it into only these four points:
1) Parts that preserve existing behavior
2) Parts added for `--by-category`
3) Whether there is any code that modifies the original CSV
4) Whether any new external package is used
Do not modify any files further right now.[Editorial example · not an actual response]
- The existing monthly total calculation is preserved, and the default run prints in the same format.
- A category-total accumulation structure and the `--by-category` condition were added.
- No code that writes to the input CSV was added.
- Only the Python standard library is used, with no new external packages.The text above is an editorial example that shows the explanation format, not the result of Claude Code reading an actual diff. In real work, compare each statement directly with the lines in `git diff`.
Even when the diff looks correct, functional verification is separate. Run the two commands verified in the previous article again to check both the default output and the option output. Because this article focuses on the git workflow, it does not repeat the Python code and assumes the already verified summarize.py is being used.
python summarize.py expenses.csv
python summarize.py expenses.csv --by-categoryThe default run should be 2026-09 = 26600 and 2026-10 = 9800. In the option run, confirm food 20500, transport 2900, and supplies 3200 for 2026-09. If the values differ, do not commit; recheck the code or input file.
After review and execution checks are complete, stage only the changed file. Then inspect `git diff --cached` once more to see exactly what will go into the commit, and commit it. Claude Code can also be asked in natural language to commit, but beginners should first learn the flow of checking which files are included before committing.
git add summarize.py
git diff --cached -- summarize.py
git commit -m "Add category summary option"
git status --shortThe official documentation notes that you can request a commit in natural language with wording such as 'commit my changes with a descriptive message'. Even if you use that feature, the principle is the same: review the diff and target files immediately before the commit. If `git status --short` is empty after the commit, there are no remaining tracked changes.
| Stage | Command or action | Purpose |
|---|---|---|
| Before work | git commit | Create a baseline to return to |
| After work | git status --short | Check the scope of changed files |
| Review | git diff | Read the actual line-by-line changes |
| Functional check | Two Python run commands | Confirm that expected output is preserved |
| Before commit | git diff --cached | Final check of what will be committed |
| Complete | git commit | Record the reviewed change as a new baseline |
Written based on the git and checkpoint descriptions in the Claude Code official documentation checked on 2026-09-22 · Does not claim that Claude Code or git commands were actually run
This article does not present an execution record of creating an actual git repository or asking Claude Code to commit. The commands form a continuous learning example; in a real project, separately check the existing branch policy, .gitignore, and whether sensitive information is included.