Git, Commits and Pull Requests

Code that is not committed does not exist yet. Git is where Claude's work stops being a change on your disk and becomes part of a project's history, with your name attached to it, so this lesson is half about mechanics and half about who is answerable for what.

Claude Code can see your git state from the moment it starts: which branch you are on, what has changed and is not committed, and the recent history. It reaches all of it the same way you would, by running git in your terminal.

Start with the read-only half

The most underrated git use is the one that changes nothing.

Ask "what have I changed since I branched off main" at the end of a long afternoon and you get a summary of a diff you would otherwise have to read in fragments. Ask it to summarise the changes to one module before you write a pull request description, and the description more or less writes itself.

Claude Code treats a built-in set of read-only shell commands as safe to run without asking, so inspecting state is unobtrusive. Anything that alters something goes through the permission system from earlier in the course.

Commit messages, and the thing it cannot know

Claude reads the diff, so it can write the half of a commit message that describes what changed. It writes that half well: accurate summary line, the right files mentioned, your project's tense and prefix conventions if the history shows them.

It cannot write the other half. Why this change exists is not in the diff. The bug report, the customer complaint, the two approaches you rejected, the ticket number — none of that is in your repository unless you put it there. And the why is the part anyone reading the history in a year actually needs.

So give it. "Commit this. The reason is that customers on annual plans were charged twice when they upgraded mid-cycle, and this fixes the double proration." That produces a message with a reason in it. "Commit this" produces a competent description of the diff and nothing more.

What a full pass looks like

claude

1. >You typed: Show me everything I've changed on this branch, grouped by what it does.

2. Claude ran: Run: git status --short

3. Claude ran: Run: git diff main...HEAD

4. Claude replied: Three groups. The proration fix in billing/proration.ts and its test. A new debug logger in billing/client.ts that prints the full invoice payload. And .env.local, which is currently untracked but staged.

5. WhyThis is why you ask before you commit. Two of those three groups should not go anywhere near the history — a debug log you forgot about, and a file with credentials in it.

6. >You typed: Drop the debug logger, unstage .env.local and add it to .gitignore. Then commit just the proration fix. Annual-plan customers were charged twice when upgrading mid-cycle; that's the reason.

7. Claude ran: Edit billing/client.ts

8. Claude ran: Run: git restore --staged .env.local

9. Claude ran: Edit .gitignore

10. Claude ran: Run: npm test billing

11. Output: PASS  proration.test.ts  (7 tests)

12. WhyIt ran the tests before committing without being told to. Worth noticing but not worth relying on — if a passing suite is a condition of committing, say so, or make it a hook later in the course.

13. Claude ran: Run: git add billing/proration.ts billing/proration.test.ts .gitignore

14. Claude ran: Run: git diff --staged

15. Claude replied: Staged three files. Here is the diff and the message I'll use — say the word and I'll commit.

16. WhyAsk for the staged diff before the commit, every time. It is the only honest account of what is going in; a summary is a description written by the thing that made the change.

17. >You typed: Go ahead, then push and open a PR.

18. Claude ran: Run: git commit

19. Claude ran: Run: git push -u origin fix/annual-proration

20. Claude ran: Run: gh pr create

21. Output: https://github.com/acme/billing/pull/482

22. >You typed: Add a note to the PR description about which customers were affected, and list anything a reviewer should be suspicious of.

23. Claude replied: Updated. The risk I'd flag: the fix changes how proration is rounded, and two other call sites use the same helper. I checked both and they round the same way, but that is the part worth a second pair of eyes.

24. WhyAsking for risks rather than a summary is the more useful question. A summary tells you what it did; a risk list tells you where to look.

Why a CLI tool is the right way out of your machine

That gh pr create deserves attention, because it is an example of a general rule worth learning once.

gh is GitHub's official command-line tool. Install it and authenticate it once, and Claude can use it to open pull requests, read comments, create issues and look at checks. Without it Claude can still reach GitHub through its public API, but unauthenticated requests run into rate limits, and you feel it at the worst moment.

The deeper reason is context. A CLI tool is the most context-efficient way to interact with an external service. One command produces a few lines of text scoped to exactly what you asked for. The alternative is authentication, several requests, pagination, and pages of JSON that all land in your context window and sit there for the rest of the session. Same information, an order of magnitude more tokens, and a slower conversation afterwards.

This generalises past GitHub. If your cloud provider, error tracker or database has a CLI, install it and tell Claude to use it. And if it is something obscure that Claude has never seen, that is usually fine — ask it to run the tool's --help first and learn the interface, then give it the task. It is good at this, and it beats describing the tool yourself.

One small bonus: a pull request created with gh is linked to the session that made it. Next week you can reopen that conversation from the pull request number with claude --from-pr 482, or paste the pull request URL into the search in the /resume picker.

Attribution

By default, commits Claude makes carry a git trailer crediting the model as a co-author, and pull request descriptions carry a line noting they were generated with Claude Code. Both are configurable through the attribution setting, which has separate keys for commits and pull requests, and setting either to an empty string removes that attribution.

Have a view on this before it becomes an argument. Some teams want the trailer because it makes the provenance of a change visible in git log. Others find it noise, or already assume it. What you should not do is discover your team's preference through a comment on your first pull request.

Where your responsibility starts

Three habits, in rough order of how often they save you.

Read the staged diff. Every time. The transcript above is not a contrived example; a forgotten debug statement and an accidentally staged local configuration file are the two most common things that get committed by accident, and both are obvious in a diff and invisible in a summary.

Keep the commit to one thing. An agent that has been working for twenty minutes has often touched more than the task needed. Say what should be in the commit rather than letting "commit my changes" decide, and be suspicious when the file list is longer than the task.

Get a second opinion on anything substantial. A fresh reviewer that did not write the code is better at finding problems in it than the session that just produced it, which has every reason to believe its own work is fine. Claude Code ships a /code-review skill that reviews the current diff in a separate context and reports back, and you can ask for risks in a pull request description as in the transcript.

Two smaller points. Checkpoints — the undo you learned about in the Foundations part — cover file edits made through Claude's editing tools. They do not cover git operations, and they are not a substitute for version control. And when you start allowlisting commands so you stop being asked, think about which git commands you are comfortable never seeing again. git status costs you nothing. Anything that rewrites or publishes history is a different question, and it is reasonable to keep being asked about that one.

What to take away

Claude can see your branch, your uncommitted changes and your history, and it can stage, commit, branch and open pull requests through the same commands you would use. It writes the descriptive half of a commit message well and cannot write the reason unless you tell it, so tell it. Reaching outside services through their CLI tools — gh above all — is the cheapest route in tokens and the most reliable in practice, and Claude can learn an unfamiliar tool from its own help output. The discipline that matters is small and non-negotiable: read the staged diff, keep each commit to one thing, and remember that the history records you as the author.

Next: debugging — pasting the real error, asking for a failing test before the fix, and refusing to accept a suppressed symptom as a solution.