Git for Vibe Coders: Version Control When AI Writes Code

Posted: May 20, 2026 to AI.

You let Claude Code, Cursor, or Copilot loose on a real project for the first time. The agent reads your files, writes new ones, edits the ones you already had, runs a few commands, and twenty minutes later something works that did not work before. It feels like magic.

Then the magic does something you did not ask for. The agent helpfully "cleans up" your authentication flow and silently drops the bcrypt step. Or it deletes a function it decided was redundant. Or it inlines a database URL with the password right there in the source. And you have no idea exactly what changed, because you let it run for forty minutes without committing once.

This is the moment every new builder meets Git, usually the hard way. Git is the system that keeps a complete history of every change to every file in your project. It runs on your laptop. It is the undo button you wish you had ten minutes ago. GitHub is the cloud service most teams use to host their Git repositories so a group of humans, and increasingly a group of AI agents, can collaborate without overwriting each other.

This post is what we tell every client who is starting to ship with AI for the first time. None of it is new. All of it is required if you want the agent to be a tool, not a liability.

Why Git matters more, not less, once an AI is committing

There is a common mistake among brand-new vibe coders: thinking that because the AI is fast, they do not need to slow down to commit. The exact opposite is true.

An AI agent makes ten or twenty edits in the time a human would make one. Without commits between those edits, you have a single giant blob of changes when something goes wrong, and no clean point to roll back to. With commits every few minutes, you have surgical control: roll back the bad attempt, keep the good parts, move on.

The simplest rule we give people: commit before you let the AI start, and commit again every time it finishes a working step. Even a commit message as basic as "checkpoint before refactor" is worth more than no commit at all.

The eight Git commands you actually need on day one

You will see hundreds of Git commands in documentation. You can ship real work with these eight.

• git init turns a folder into a Git repository.
• git clone <url> downloads a copy of a remote repository to your machine.
• git status shows what you changed, what is staged, and what is new and untracked. Run it constantly.
• git add <files> stages specific files for the next commit. Use file names, not git add ., when you have anything sensitive nearby.
• git commit -m "why this change" takes a snapshot with a message future-you can read.
• git push origin <branch> uploads your commits to the remote so others can see them.
• git pull origin <branch> downloads new commits from the remote.
• git checkout -b <branch> creates a new branch and switches to it. One AI session, one branch.

Memorize these eight and you can survive your first month of AI-assisted coding without losing work.

The .gitignore file is your first line of defense

The single most important file in your repository, before you commit even one line of code, is .gitignore. It is a plain-text file listing patterns of files Git will refuse to track.

Here is the minimum every new project needs in its .gitignore:

• .env and .env.local
• *.pem and *.key
• secrets/
• node_modules/ or whatever your language's dependency folder is
• .vscode/ and .idea/ editor settings
• dist/, build/, or anything generated

Add this file before your first commit. Once a file has been committed and pushed, .gitignore cannot retroactively scrub it from history. Every secret you ever pushed to a public repository is still in the history, indexed, and available to anyone with a search bar.

The leaked-secret nightmare, and what to actually do about it

This one deserves its own section because it is the single most expensive mistake new vibe coders make.

You commit a file. The file has an AWS access key in it, or a Stripe live key, or a database connection string with the password embedded. You push to GitHub. Within minutes, automated scrapers find the key. Within hours, crypto-mining bots are spending your AWS bill or your Stripe account is being drained.

People then ask the obvious question: how do I delete that commit? The honest answer is: you do not. A leaked AWS key in git history is permanent unless you rewrite history, and even then crawlers have already grabbed it. The fix is rotation, not deletion. Specifically:

1. Rotate the key at the provider. Right now. Before anything else.
2. Then, if you want clean history, use a tool like git filter-repo or BFG Repo-Cleaner to strip the secret from past commits.
3. Force-push the cleaned history, then ask every collaborator to re-clone.
4. For any work under CMMC, HIPAA, PCI, or an NDA, treat this as a reportable incident. There is paperwork.

The reason rotation comes first is that even if you erase the commit from your repository, every clone, every fork, and every search index already has it. The key is burned.

Why branch protection on main is the single best control

The most useful security feature in GitHub is also the simplest. On the settings page of any repository, you can require that changes to your main branch go through a pull request, that the pull request gets at least one approval, and that automated tests pass before the merge button is clickable.

This one setting prevents almost every "the AI shipped something dangerous" disaster we have ever investigated. An agent with push access to main can ship anything the moment its prompt gets hijacked. An agent with push access only to feature branches, where a human reviews the pull request, can be wrong without being catastrophic.

Turn it on for every repository before you give an AI agent commit access. Especially turn on the rule that says "do not allow force pushes." Force-pushing main is how a compromised credential or a confused agent quietly erases the evidence of what just went wrong.

What a good commit message looks like

Most AI agents will, if you let them, write commit messages like "fix bug" or "update files" or worse, "changes." These are signals that the model was not paying attention to why the change exists. Future-you, reading the log six months later, will hate past-you for accepting them.

A good commit message has a short summary line, under 72 characters, that says why the change exists, followed by an optional longer body that gives context. For example:

Bad: fix login

Good: Replace MD5 with bcrypt in login flow, fixes CMMC IA.L2-3.5.10

The second one tells you, without opening the diff, what changed and why. It also references a specific compliance control, which is exactly what an auditor wants to see when they walk through your repository six months from now.

The two-minute Git hygiene checklist

If you do nothing else from this post, run these six steps on every project before you let an AI agent commit:

1. Create a .gitignore with .env, *.pem, secrets/, and any sensitive folder before your first commit.
2. Install a secret scanner like gitleaks or git-secrets and configure it as a pre-commit hook.
3. Push to a private GitHub repository. Public is for code that has been reviewed for sensitive material first.
4. Turn on branch protection for main: pull request, review, passing tests, no force pushes.
5. Make every AI session run in its own feature branch, never directly on main.
6. Read the diff of every pull request yourself before merging. The summary is not the diff.

Two minutes of setup, every time, saves a week of incident response. We have watched both sides of this trade play out at clients.

Where Petronella fits

If your AI-assisted work is touching customer data, regulated workloads under HIPAA or CMMC, or anything covered by an NDA, the version-control story stops being a personal-productivity question and becomes a compliance question. Petronella Technology Group has been helping North Carolina businesses navigate exactly that since 2002. Craig Petronella holds CMMC-RP RPO #1449, NC DFE #604180, CCNA, and CWNE. We help clients lock down GitHub organizations, recover from leaked-secret incidents, and prepare repositories for CMMC and HIPAA audits.

If you want the printable one-page Git field guide for the wall next to your monitor, or if you need help letting your team use AI-assisted coding without burning down your compliance posture, we can help.

Get the Git + GitHub Field Guide

Or call us at (919) 348-4912. Penny answers 24/7 and can put you on the calendar with a human who has done this before.