1. Find the right checkout
Open the repository or worktree where Claude Code made its edits. Check the active branch and working-tree status before reviewing. A second checkout can show a different diff even when both folders belong to the same repository.
In a terminal, these read-only commands establish the starting point:
git status --short --branch
git diff --stat
git diff
git diff --cachedThe unstaged and staged diffs show different parts of your pending commit. Also inspect untracked files: they do not appear in an ordinary git diff. In GitGlow, select the affected checkout and open Changes.
Read the worktree guide if you need to identify an isolated checkout.
2. Review the change, not the summary
Read each changed file in context. Does the patch solve the requested problem? Look for changed public interfaces, error paths, new dependencies, generated files, and edits outside the task. Open the surrounding source when a diff alone leaves behavior unclear.
If you connected a supported Claude session to GitGlow, Agent Observatory can add run and attributed-file context. Git status remains the inventory of pending work; attribution does not establish that every edit came from the agent or that it is correct.
Read the diff-review controls or connect supported Claude activity.
3. Work through a concrete example
Suppose you asked Claude Code to fix a discount calculation. Your working tree now contains a pricing function, its tests, a lockfile, and a README edit you started earlier. Those four files need four decisions.
- Pricing function: check the arithmetic and rounding. A $50 item with a 20% discount should cost $40. Inspect zero, full-discount, and invalid-input behavior against your requirements.
- Tests: confirm that they cover the original failure and meaningful boundaries. A rewritten assertion that accepts the wrong result is not evidence of a fix.
- Lockfile: identify why it changed. If the task needed no dependency update, resolve that change separately before staging.
- Your README edit: leave it out of this commit. If unrelated changes share a file, review and stage the relevant hunks or supported lines individually.
This is an illustrative review exercise. It shows how to decide commit scope, not a claim that GitGlow can determine the correctness of a pricing function.
4. Verify the version you reviewed
Run the project’s relevant checks in the same checkout: the regression test, affected tests, and any required lint or build check. Inspect failures before treating the change as ready. For a UI fix, exercise the interaction too.
With GitGlow Pro, mark reviewed files and use configured verification checks. Later file edits invalidate review marks and can make earlier verification stale. If Claude keeps editing while you review, let the work settle, reread the affected diffs, and rerun checks that the new changes could affect.
A passing check records what you ran. It does not prove that the requirements are complete or that the code has no defects. Read review confidence and verification.
5. Stage a focused commit
Stage the reviewed implementation and relevant tests. Read the staged diff once more before committing; the working tree can still contain unrelated changes. Describe the behavior fixed in the commit message, then check status again.
git diff --cached --stat
git diff --cached
git status --shortIn GitGlow Free, you can stage files, hunks, and supported selected lines. Commit preparation is separate from pushing, merging, or publishing a release. Read staging and commit controls.
Common questions
Do I need to connect Claude to review its changes?
No. The Git diff is available without an agent connection. A supported connection adds activity context; it does not replace file review.
Can GitGlow control a Claude session started elsewhere?
Observed sessions remain owned by their originating client. Available controls depend on the supported connection and how the run started. Check approvals and handoffs before relying on a control.
Does this also work for other coding agents?
The Git review sequence applies to changes made by any tool or person. Agent connections and managed controls have their own supported-provider requirements.
Which Git client should I use?
Choose based on the workflow and providers you need. Our GitGlow vs GitKraken comparison covers local Git, agent review, pricing boundaries, and hosted integrations.