Claude Code can drive branch creation, commits, pushes, and PR descriptions — but the underlying git discipline, and the decision of what actually gets pushed, stays exactly the same as doing it yourself.
1A Commit Should Contain Exactly One Coherent Change
Staging only the files actually part of the current feature — not every uncommitted file sitting in the working directory — keeps the resulting pull request reviewable as one thing and safely revertible if it needs to be. This discipline doesn't change just because Claude Code is driving the git commands.
2Pushing and Opening a PR Stay Deliberate Actions
Consistent with the risk-graded permission system from Module 1, actions that leave your local machine — a push to a remote branch, opening a pull request — are exactly the kind of action worth keeping gated, reviewed and approved each time rather than pre-approved for a whole session.
3Step-by-Step Breakdown
From Working Code to a Real Pull Request. The export feature is built, tested, and reviewed. Shipping it means the same git workflow you'd use yourself: a branch, a focused commit, a pushed branch, and a pull request with a description that actually explains the change — and Claude Code can drive every step of it, still asking permission for the ones that touch shared state.
A Focused Commit, Not Everything at Once. Notice the commit only stages the five files that are actually part of this feature — not any other uncommitted work sitting in the repo. Claude Code will ask before running git add and git push, exactly the risk-graded permission behavior from Module 1's loop.
Why does it matter that the commit only stages the five files actually part of the export feature, rather than every changed file in the working directory?
- →A focused commit keeps the pull request reviewable and revertible as one coherent change — bundling in unrelated files makes the diff harder to review and could accidentally ship unfinished, unrelated work.
- →Git enforces a hard limit on how many files a single commit can contain.
Write the Pull Request Description. A good PR description explains the why, not just restates the diff. Draft one for the export feature using what you actually know about it from this masterclass.
Same Rules, Real Stakes. Nothing about this workflow is special to AI — it's the same branch, commit, push, and PR discipline any careful engineer follows, with Claude Code driving the mechanics and you still deciding what actually gets pushed and opened. Next lesson: the security and review discipline that has to hold even when the code arrived fast.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
N/A — this workflow runs via git in the terminal, though the PR itself is typically opened on a web host like GitHub.
N/A — this workflow runs via git in the terminal, though the PR itself is typically opened on a web host like GitHub.
N/A — this workflow runs via git in the terminal, though the PR itself is typically opened on a web host like GitHub.
N/A — this workflow runs via git in the terminal, though the PR itself is typically opened on a web host like GitHub.
Accessibility (A11y)
1Write PR Descriptions That State the Why, Not Just the Diff
A description explaining the reasoning behind a change (and a concrete test plan) is more useful to any reviewer — including one relying on a screen reader to navigate a long diff — than one that simply restates file names.
SEO Implications
- 1
Target 'Claude Code git workflow' and 'writing a good pull request description' separately
Users search for the tool-specific mechanics and for the general PR-writing skill as distinct questions.
Best Practices
Stage Only the Files Actually Part of the Current Change
Even when Claude Code is driving `git add`, confirming the staged file list matches exactly what the task touched keeps commits focused, reviewable, and safely revertible.
Frequent Bugs
Letting a commit sweep in unrelated uncommitted files sitting in the working directory alongside the intended change.
Review the staged file list before committing and keep it scoped to exactly the files that are part of the current, reviewed change.
Real-World Examples
The Bundled Unrelated File
While committing the export feature, an unrelated in-progress file from a different task was still sitting uncommitted in the working directory. Reviewing the staged file list before approving the commit caught it, keeping the export feature's PR focused on exactly what it claimed to change.
// Caught before commit: git status showed an unrelated file staged
// Fixed: unstaged it, kept the commit scoped to the export feature