Git Workflows for Vibe Coding

When you write the code, you know what went into each commit — every file you touched, every decision you made, every tradeoff you accepted. When the agent writes the code, you know the prompt you gave it, but you did not write the commit. You did not decide which files to group together. You did not write the commit message. And you almost certainly did not review every line of the diff before it landed.

This changes everything about how you use git. You need a workflow that gives you visibility into what the agent did, lets you review it on your own terms, and gives you a clean way to undo when the agent goes off track. The workflow itself is not complicated — branch per feature, commit what the agent was asked to build, review the diff, squash and merge. But every step has a vibe-coding-specific reason it exists, and skipping any step means losing control of your codebase.

What you'll learn

• When the agent writes the code, your git workflow becomes your primary review and safety mechanism — not an afterthought, not "just version control," but the system that lets you inspect, approve, undo, and ship agent-authored changes
• Branch per feature, commit per prompt — each prompt gets its own commit with a message that records what the agent was asked to build, so you can trace any line of code back to the instruction that produced it
• Review every AI-authored diff before merging. Not because the agent is untrustworthy, but because you are the only one who knows whether the output matches what you actually wanted
• Commit before every auto-approve session — it is your undo button. If the agent runs wild, git reset --hard HEAD puts everything back

The problem: you did not write this code

In a traditional workflow, you type the code, you stage the files, you write the commit message, and you know exactly what changed and why. In a vibe-coded workflow, the agent types the code, and you are left with a working tree full of changes you did not personally make. Your job shifts from "write the code" to "review the code," and git is the tool you use to do that review.

Without a git workflow, here is what happens:

• You give the agent three prompts in one session. It touches 12 files across four directories. You cannot tell which prompt produced which changes.
• The agent adds a feature you did not ask for. It is buried in a 20-file diff. You merge it without noticing. Three weeks later, a bug in that unwanted feature takes down production.
• The agent makes a breaking change. You do not have a clean commit to revert to because you never committed between prompts. You spend an hour manually undoing changes instead of one git revert.
• You want to show a teammate what the agent built for a specific prompt. You cannot because all the changes are mixed together in one giant commit titled "updates."

The git workflow for vibe coding exists to prevent every one of these scenarios.

Options & when to use each

Approach	What it is good for	What it costs you	When to pick it
No git (direct to main)	Nothing. Do not do this	No undo; no review; no history; no way to collaborate	Never, unless you are experimenting in a throwaway directory
One branch, one commit per session	Quick solo projects where every session produces a small, coherent set of changes	Hard to isolate a single prompt's changes if a session contains multiple prompts	Solo projects with short, focused sessions
Branch per feature, commit per prompt (this lesson)	Full traceability: every prompt is a commit, every feature is a branch, every change is reviewable	More branching overhead; requires discipline to commit after every prompt	Any project you intend to maintain, share, or deploy
Trunk-based with feature flags	Continuous deployment teams that ship multiple times per day	Feature flags add complexity; requires a deployment system that supports them	Teams shipping to production multiple times per day — not typical for vibe-coded solo projects

The branch-per-feature, commit-per-prompt workflow is the right default for vibe coding. It gives you the maximum visibility and control with the minimum overhead. A branch takes two seconds to create. A commit takes ten seconds. Together they save you hours of debugging and manual recovery.

Build it: the branch-per-prompt workflow

This is not a git tutorial. We assume you know the basics: git init, git add, git commit, git branch, git checkout, git merge. If those are unfamiliar, start with Practical Fundamentals first. What follows is the specific workflow for vibe-coded projects — the steps you take before, during, and after every agent session.

Step 1: before every session — checkpoint

# Make sure you are on main with a clean working tree
git checkout main
git status   # should show "nothing to commit, working tree clean"

# Create a feature branch
git checkout -b feature/monthly-revenue-report

The branch name tells you what you are building. Use a consistent naming convention: feature/, fix/, refactor/ prefixes make it easy to scan your branch list and know what each branch contains.

If you are running the agent in auto-approve mode (--dangerously-skip-permissions), make an extra checkpoint:

git add -A && git commit -m "checkpoint before auto-approve session"

This is your undo button. If the agent goes off track in auto-approve mode, git reset --hard HEAD reverts everything. One command, zero drama.

Step 2: during the session — commit after every prompt

After the agent completes a prompt, do not immediately give it the next prompt. Review the changes first:

# See what changed
git diff --stat          # which files changed
git diff                 # the actual changes

# Stage and commit
git add -A
git commit -m "feat: add monthly revenue report route and template

Prompt: Add a monthly revenue report page at /reports/revenue with a month
selector, summary card, and category breakdown table. Follow the spec at
specs/monthly-revenue-report.md."

The commit message format matters. Use conventional commits: feat: for new features, fix: for bug fixes, refactor: for restructuring, test: for tests. But the more important part is the body: include the actual prompt you gave the agent. Three months from now, when you look at this commit and wonder "why is this code here?" the answer is right there in the commit message — it is what you told the agent to build.

If the agent's output is not what you wanted, do not commit. Instead:

# Discard the agent's changes and try again
git checkout -- .

Or if you want to keep some changes but redo others:

# Unstage everything
git reset HEAD

# Stage only the files you want to keep
git add app/routes/reports.py

# Discard the rest
git checkout -- .

# Commit what you kept
git commit -m "feat: add reports route (partial)"

Step 3: the review workflow — before you merge

When the feature is complete — all prompts executed, all commits on the branch — do a full review before merging:

# See every change on this branch
git diff main...feature/monthly-revenue-report

# Or, easier to read: the log of commits
git log main..feature/monthly-revenue-report --oneline

Review the full diff, not just the most recent commit. The agent may have made a mistake in prompt 2 that it "fixed" in prompt 4 by working around it instead of correcting it. The workaround might be fragile. The full diff shows you the complete picture.

Things to look for in an AI-authored diff:

• Code that does not match the prompt. The agent added a chart library to the report page but you never asked for charts. This is the most common AI drift — the agent fills in blanks with features you did not request.
• Duplicated code. The agent wrote a helper function in reports/routes.py that already exists in dashboard/routes.py. You can refactor now, or open an issue to refactor later, but you need to know the duplication exists.
• Inconsistent patterns. The agent used camelCase in one file and snake_case in another. Catch this before it spreads.
• Hardcoded values. The agent hardcoded a database path, an API key placeholder, or a configuration value that should be an environment variable.
• Missing error handling. The happy path works. What about when the database is empty, the API is down, or the user submits invalid input?

If you find issues, you have two choices, and the choice depends on severity:

Minor issues (typo, wrong variable name, missing comment): fix them directly on the branch. The agent did 95% of the work; you do the last 5%.

# Fix the issue manually
vim app/routes/reports.py
git add app/routes/reports.py
git commit -m "fix: correct CSV column header name"

Major issues (wrong architecture, missing feature, agent misunderstood the prompt): ask the agent to fix it.

# Give the agent a targeted fix prompt
claude
> The revenue report route at @app/routes/reports.py uses server-side rendering
  with Jinja2, but the spec says it should return JSON for the frontend to consume.
  Rewrite it as a JSON API endpoint following the contract in
  @specs/monthly-revenue-report.md.

Step 4: merge and clean up

When the review passes:

git checkout main
git merge feature/monthly-revenue-report
git push origin main
git branch -d feature/monthly-revenue-report

If you are collaborating with others or want an extra review step, open a pull request instead of merging directly. The PR gives you a place to paste the spec, link to the prompts, and get a second pair of eyes on the agent's output before it lands in main.

Step 5: the emergency undo

Sometimes the agent does something you did not intend, and you do not notice until later. The undo depends on how far the bad change has traveled:

Bad change is the latest commit, not pushed:

git reset --hard HEAD~1

Bad change is a few commits back, not pushed:

git log --oneline   # find the commit hash before the bad change
git reset --hard <safe-commit-hash>

Bad change is already pushed:

git revert <bad-commit-hash>
git push origin main

git revert creates a new commit that undoes the bad one. This is safer than git reset on a shared branch because it does not rewrite history. If someone else pulled your bad commit, they will get the revert cleanly.

Bad change happened in auto-approve mode and affected multiple files:

# If you checkpointed before the session:
git reset --hard HEAD

# If you did not checkpoint (lesson learned):
git diff HEAD~1 --stat   # see every file that changed
git checkout HEAD~1 -- path/to/broken/file   # restore one file at a time

What goes wrong

Mistake	How you notice it	The fix
Not committing between prompts	You give the agent three prompts in one session. Prompt 3 produces a bug. You cannot isolate prompt 3's changes because they are mixed with prompts 1 and 2 in an uncommitted working tree	Commit after every prompt. One prompt, one commit. If prompt 3 is broken, revert prompt 3, not the entire session
Commit messages that do not include the prompt	Three months later, you look at a commit and have no idea what the agent was asked to build. The code makes sense in isolation but you cannot tell if it is correct because you do not know the original intent	The commit body is where the prompt goes. "feat: add revenue report" is the subject line; the actual prompt you typed is the body
Merging without reviewing the full diff	You review the last commit on the branch, which looks fine. But the agent made a mistake in the first commit and "fixed" it with a workaround in the third. The workaround is fragile and will break next week	Always review git diff main...feature/branch — the full diff against main, not just the tip commit
Auto-approve without a checkpoint commit	You run --dangerously-skip-permissions without committing first. The agent goes off track. You have no clean state to revert to	git add -A && git commit -m "checkpoint" before every auto-approve session. Two seconds of typing saves hours of recovery
Squashing everything into one commit	You squash a 10-prompt feature branch into a single commit with the message "add revenue report feature." You lose the traceability from individual prompts to individual changes	Keep the per-prompt commits. Squash only trivial fixup commits ("fix typo," "address review comment"), not the substantive ones
Not pushing regularly	Your laptop dies. You lose a week of work because everything was only on your local machine	Push after every merged feature. git push origin main should be as automatic as git commit

Confirm it worked

Run through the full workflow on a small feature:

1. git checkout -b feature/test-workflow
2. Give the agent one prompt. Review the diff. Commit with the prompt in the body.
3. Give the agent a second prompt. Review the diff. Commit.
4. Run git log main..feature/test-workflow --oneline. You should see exactly two commits, each with a descriptive message.
5. Review the full diff: git diff main...feature/test-workflow. You should understand every change and why it was made.
6. Merge: git checkout main && git merge feature/test-workflow.
7. Delete the branch: git branch -d feature/test-workflow.

Now try the emergency undo. On a throwaway branch, run the agent in auto-approve mode (after a checkpoint commit) and give it a deliberately destructive prompt: "Delete all comments and docstrings in the project." Watch it wreak havoc. Then: git reset --hard HEAD. Everything is back. This is not a hypothetical — run it once so you trust the undo button when you need it for real.

The final confirmation: three months from now, you open the git log for your project and you can trace every feature back to the prompts that built it. You know what the agent was asked to do, what it actually did, and why each decision was made. The git log is no longer a list of timestamps — it is the story of your project, told one prompt at a time.

Next: CI/CD for Vibe-Coded Applications