Git, commits and pull requests

What you’ll be able to do

Go from a finished change to a reviewed pull request with a clear description, using Claude for the git busywork (commits, branches, PR descriptions, reviews, conflicts) while you stay in control of what’s shipped.

Why this matters

Writing good commit messages, splitting unrelated changes, writing a useful PR description and reviewing your own code before others see it are all valuable, and all easy to skip when you’re busy. Claude Code is very good at these tasks, because they’re mostly about reading a diff carefully and describing it clearly.

There’s one important boundary: git operations publish your work. A push or a PR is visible to your team, and a force-push can overwrite other people’s work. This lesson shows how to let Claude do the typing while you keep the final say over what leaves your machine.

Prerequisites

• A GitHub account and the GitHub CLI (gh), installed and logged in with gh auth login. Claude uses gh to create PRs and read review comments.
• A GitHub repository you can push to. To publish your loop-practice project as a new private repository, run this from the project folder:

gh repo create loop-practice --private --source . --push

Commits with meaning

After finishing a change, ask:

Review the staged and unstaged changes and commit them with a conventional
commit message. If the changes are unrelated, split them into separate commits.

What you’ll see: Claude runs git status and git diff, groups related changes, and proposes one or more commits with messages such as feat: add truncate helper with tests. It asks before running git commit (depending on your permission mode).

Conventional Commits is a widely used message format: a type (feat, fix, docs, test, refactor…), a colon and a short summary. It makes history easy to scan and works with tools that generate changelogs. Claude’s real strength here is explaining the why of a change in the message body, not just the what.

Branches and pull requests

Create a branch feat/truncate-helper with the current changes, push it, and
open a PR against our default branch. The description should explain the
motivation, the approach, and how it was tested.

What you’ll see: Claude runs git checkout -b, git push -u origin … and gh pr create, then gives you the PR’s URL. The description is written from the actual diff and conversation, so it’s usually more complete than one written in a hurry.

Self-review before teammates see it

Reviewing your own diff before others do catches embarrassing mistakes cheaply. Ask for a structured review:

Review this branch's diff against main as a strict senior reviewer:
correctness bugs, missing edge-case tests, unclear names, leftover debug code.
List findings by severity with file:line. Don't change anything yet.

(Replace main with your default branch’s name if it’s different, such as master.)

What you’ll see: a numbered list of findings, most severe first, each with a file and line. “Don’t change anything yet” keeps you in control: you decide which findings matter. Then:

Fix findings 1 and 3. Skip 2, which is intentional.

Built-in review commands

Claude Code also ships ready-made review commands you can run directly:

Command	What it does
/code-review (alias /review)	Finds correctness bugs in your branch’s changes. Runs as a background subagent so it doesn’t fill your context
/code-review high --fix	Reviews at higher effort, then applies the fixes (edits still go through your permission mode)
/code-review 1234 --comment	Reviews PR #1234 and posts the findings as inline PR comments
/simplify	Cleanup only: reuse, simplification, efficiency. Applies its fixes
/security-review	Looks for vulnerabilities (injection, auth issues, data exposure) in your branch versus origin
/code-review ultra	A deeper, multi-agent ultrareview in the cloud (needs a claude.ai account; billed separately)

When should you use which? Use your own structured prompt when you want a particular review style or focus. Use /code-review for a fast, consistent bug hunt; it runs in the background, so you can keep working while it reviews. /code-review follows your CLAUDE.md, so your team’s conventions apply automatically. /security-review needs your repository to have a remote called origin, which it compares against.

Dealing with review comments

When teammates review your PR, Claude can work through their comments:

Read the review comments on PR #12 with gh, address each one, and reply to
each comment summarising what you changed.

What you’ll see: Claude fetches the comments with gh, makes the changes, and drafts replies. Read the replies before they’re posted: they speak for you.

Merge conflicts

When your branch and the main branch changed the same lines, git can’t combine them automatically:

I'm rebasing on main and have conflicts. Resolve them, keeping both features
working, run the tests, and explain each resolution.

Exercise

Using your loop-practice repository on GitHub (see Prerequisites):

1. Ask Claude to add a capitalize(text) helper with tests.
2. Have it create a branch, commit with a conventional message, push, and open a PR. What you’ll see: a PR URL. Open it on GitHub and read the description.
3. Run /code-review, plus your own strict self-review prompt from above, and fix at least one finding.
4. Ask Claude to commit and push the fix. What you’ll see: the new commit appears on the same PR.

Common mistakes

• Letting Claude commit everything automatically. Review the diff first; add “only commit when I ask” to CLAUDE.md.
• Unrelated changes in one commit. Ask Claude to split them; it makes review and reverting much easier.
• Not reading conflict resolutions. A clean merge isn’t necessarily a correct one.
• Posting replies without reading them. Replies to review comments go out under your name.

Verify it worked

• A PR exists with a clear description written by Claude
• The commits follow a consistent message convention
• You ran /code-review or a self-review and fixed at least one finding
• The fix appears as a new commit on the same PR