What is Git? Commits, branches and pushes, explained for vibe coders

What it actually is

Git is a save-and-rewind system for a folder of files. Instead of one file called project-final-v3.zip, every meaningful change gets its own labeled snapshot, called a commit, and Git remembers the whole chain of them in order. It’s like the version history in a Google Doc, except it tracks changes across your entire project (every file, every rename, every deletion) and lets you jump back to any snapshot on demand.

Two words trip people up early: branch and push. A branch is a separate timeline of commits that starts as a copy of your main work. Your agent can build a login page on a branch called add-login while main stays untouched, then merge the two back together once it works. Push is the separate step of copying your commits from your laptop up to a remote copy, usually on GitHub. Until you push, your commits only exist on your machine.

Why your AI just did this

Your agent commits constantly because a commit is its checkpoint. Before a risky edit (rewriting auth.ts, upgrading a package in package.json) it wants a save point to fall back to if the change breaks something. After a good edit, it commits again so that working state is locked in rather than sitting loose, one prompt away from being overwritten.

It creates a branch, something like git checkout -b fix-payment-bug, when it wants to try an idea without touching what already works. If the experiment fails, it can throw the branch away and main never knew anything happened. If it succeeds, it merges the branch back in. This is also why you’ll see it run git status or git diff mid-task. It’s checking what actually changed before deciding what’s worth saving, the same way you’d reread a paragraph before hitting save.

When you’ll run into it

You’ll see git status report “Changes not staged for commit,” meaning files were edited but not yet saved into a commit. You’ll see “Your branch is ahead of ‘origin/main’ by 2 commits,” meaning you have local saves that haven’t been pushed anywhere yet. You’ll hit merge conflicts, where Git can’t decide between two versions of the same lines and drops markers like <<<<<<< HEAD straight into your file for someone, or your agent, to sort out.

Your tool may pause to ask permission before running git push to a shared repo, or before a force push, which overwrites remote history instead of adding to it. And the moment this stops being abstract: you ask your agent to “put it back like it was yesterday,” and it either finds that state in the commit history or has to admit there’s nothing to go back to.

What to check

• Run git log --oneline now and then so you can see there’s an actual trail of commits, not one giant blob of unsaved changes
• Confirm .gitignore lists node_modules and .env. You don’t want dependencies or secrets committed and pushed to GitHub
• Before a big or risky change, have your agent commit the current working state first, so “undo” has somewhere to land
• Run git remote -v to confirm exactly which GitHub repo, and whose, your pushes are landing in
• If your agent creates a branch, ask what it’s for and whether it plans to merge it back. A forgotten branch can quietly hold your best fix

Say it like a dev

Instead of: “I don’t save often enough to just undo everything” Say: “Commit the current working state now, before you touch anything else.”

Instead of: “undo what you just did” Say: “Revert the last commit” for something already saved, or “discard the uncommitted changes in auth.ts” for something that isn’t.

Instead of: “just try it and see what happens” Say: “Make a new branch for this so main stays safe.”