Lesson 13: Git Workflows

Day 13 of 50 · ~7 min read · Phase 2: Core Workflows

The Opening Question

You've made a set of changes across your codebase. Claude created them. They work. Tests pass. But now you need to ship them.

You could commit the changes yourself. But what if Claude could stage the files, write a clear commit message, create a branch, push to remote, and even open a pull request?

Here's the question: Can Claude really be your partner in version control workflows? And more importantly, should you let it?

The answer gets at trust, coordination, and how we think about code review in an AI-assisted world.

Discovery

Let's build understanding of how Claude Code works with git.

Question 1: Why would Claude handle git operations?

Think about a typical workflow:

1. You ask Claude to implement a feature
2. Claude reads code, makes edits, runs tests
3. Tests pass
4. Now you need to commit

The old way: You manually stage the files, write a commit message, push to a branch. This is mechanical. It's also error-prone — you might forget a file, or write a vague commit message.

Claude can do this. It can:

• See which files changed (git status)
• Stage files (git add)
• Write clear commit messages that explain why the change exists, not just what changed
• Create branches (git checkout -b)
• Push to remote (git push)
• Even open a pull request (gh pr create)

But here's the key question: Why is it valuable for Claude to handle this instead of you?

Pause and think: What's the difference between a commit message written by a human and one written by Claude?

A human might write: "fixed bug" or "added feature." Claude, having just done the work and seen the code, can write: "Add retry logic to email delivery with exponential backoff. Prevents cascading failures when mail service is temporarily down. Retries up to 3 times with 2-second base delay."

More importantly: Claude doesn't forget files. If it made changes to 7 files, it stages all 7. A human might stage 6 and forget one, breaking the next build.

Question 2: When should Claude stage and commit changes?

Here's a design decision: should Claude automatically commit changes as it makes them, or wait for your approval?

The answer is: it depends on context.

If Claude makes a small, focused change (adding a single function, fixing a single bug), it might ask your approval first: "I've made these changes. Should I commit them?" You review, approve, and Claude commits.

If Claude is working autonomously on a larger task (refactor a module, add a feature), it might commit as it goes, creating a series of logical commits that tell the story of the work: "Commit 1: Extract validation logic. Commit 2: Update callers of validation. Commit 3: Add tests." This creates a readable history.

You stay in control. You can ask: "Don't commit yet, let me review" or "Commit this, but hold off on the next phase until I review."

Pause and think: Why would breaking a large change into multiple logical commits be better than one giant commit?

Because when someone reviews your code (or you review it later), each commit tells a story. Each one is understandable on its own. If something goes wrong, you can git revert a single commit. If it's all in one monster commit, you lose that granularity.

Question 3: How does Claude handle branches and pull requests?

Real projects don't commit directly to main. They use branches and pull requests.

Claude can:

1. Create a new branch (git checkout -b feature/add-retry-logic)
2. Make changes
3. Commit to the branch
4. Push the branch to remote (git push origin feature/add-retry-logic)
5. Create a pull request using the GitHub CLI: gh pr create --title "..." --body "..."

Claude even writes good PR descriptions. It can explain what the change does, why it was needed, how to test it, and what files changed.

The power here: You don't need to do the administrative overhead of version control. You focus on what matters: reviewing the code and deciding whether to merge.

But there's a responsibility: you still review the PR. You read the description. You check the diffs. You run the tests (or trust that they ran automatically). You either approve it or ask Claude to revise.

Pause and think: If Claude creates a PR with a great description and tests pass, is that enough to merge? Or should you always review the code yourself?

Always review. Automated tests catch some errors, but not all. They catch behavioral problems, not style issues or architectural concerns. That's your job.

Question 4: What about merge conflicts and tricky git situations?

Real projects sometimes have merge conflicts. Two people edit the same file. One person changes a function while another person renames it.

Can Claude handle this? Actually, yes. It can:

1. See the conflict markers
2. Read the conflicting sections
3. Understand what each side was trying to do
4. Propose a resolution

For example:

• Developer A changed loginUser() to authenticateUser() and updated all callers
• Developer B added logging inside the old loginUser() function
• Conflict: the function was renamed, but the old name has new code

Claude can reason: "The function was renamed to authenticateUser. The new logging should go into that function. Let me apply the logging to the renamed version."

Claude can also use git worktrees for parallel work — maintaining multiple branches simultaneously without constantly switching. This is advanced stuff, but the point is: Claude is capable enough to handle the git complexity of real projects.

Pause and think: Why would it be valuable for Claude to understand git history, not just the current state?

Because context matters. If Claude is resolving a conflict, knowing why the change was made (reading the commit message of the conflicting commit) helps it resolve correctly. If Claude is reviewing code, understanding the history of a file (what changed, when, why) informs whether a change is good.

The Insight

Here's the core idea about Claude and version control:

Version control is essential infrastructure for teams and for maintaining a readable history of your work. Claude Code can handle the mechanical parts of git — staging, committing, branching, pushing — with the added benefit of writing clear commit messages and understanding dependencies across files. You stay in control by reviewing branches before merge, reading pull request descriptions, and deciding what gets shipped. Git becomes less overhead and more communication.

The mental model: Think of Claude as your pair-programming partner who handles the administrative work of version control. You focus on the creative and critical parts (designing the solution, reviewing the code, making merge decisions). Claude handles the mechanics (which files changed, what's the commit history, does this branch align with main).

Try It

You're going to experience Claude's git workflow.

1. Start in a git repository (create one if needed):

   cd your-project
   git init
   git add .
   git commit -m "initial commit"
   

2. Start a Claude conversation: claude

3. Ask Claude to implement a feature and handle the git workflow:

   • "Implement a new endpoint that returns user stats. Create a branch for this, make the changes, and commit them with a clear message."
   • "Refactor the authentication module and create a pull request when done."

4. Watch Claude work. Notice:

   • Does it create a branch before making changes?
   • Does it stage the right files?
   • What does the commit message look like?
   • Does it push to remote?
   • Does it offer to create a PR?

5. If Claude offers to create a PR:

   • Read the PR description. Is it clear?
   • Look at the diffs. Are they correct?
   • Approve or ask Claude to revise

6. Afterward, examine the git history:

   git log --oneline
   git show <commit-hash>
   

   This shows you the quality of Claude's commit messages and organization.

7. Reflect: Did Claude's approach to git workflows make sense? Would you trust Claude to handle branching and committing as part of larger tasks?

Key Concepts Introduced

Bridge to Lesson 14

You've now seen Claude work through multi-file operations and version control workflows. You understand how to ask Claude to do complex tasks and trust it to handle the mechanical parts.

But understanding is one thing. Doing is another.

Next lesson is a lab: You're going to apply everything you've learned in Lessons 9–13 to a real refactoring project. You'll use Claude to read code, make coordinated multi-file edits, run tests, fix problems, commit changes, and create a pull request.

This is where theory becomes practice.

← Back to Curriculum · Lesson 14 →