Git is the rope tied around your waist before entering the cave
Git is not there to make you feel stupid.
Git is there so that when the AI “improves” your working app into a pile of fresh architecture soup, you can return to the last version that behaved like a citizen.
If vibe coding is fast, Git is the save point system.
Use the save point.
Every gamer understands this instinctively.
You do not enter the boss room after twenty minutes of progress without saving. You save because you have seen things. You know the music changed. You know something large is breathing behind the door.
AI-generated code is often that boss room.
The assistant says:
I’ll just refactor this component.
The music changes.
Commit first.
What Git does
Git tracks changes in your project over time.
That is the simple version.
More specifically, Git lets you:
- save snapshots of your project;
- see which files changed;
- compare old and new code;
- create branches for experiments;
- restore files;
- roll back mistakes;
- collaborate with other people;
- avoid storing your entire project as
final,final2,final-real,final-real-working, andfinal-real-working-use-this-one-please.
Git does not make your code good.
It makes your mistakes recoverable.
That is enough to make it holy.
Why vibe coders need Git earlier than they think
Many beginners delay Git because it feels like “developer stuff.”
This is understandable.
Git has words like HEAD, branch, merge, rebase, and detached HEAD, which sounds less like software and more like a Victorian medical incident.
But vibe coders need Git immediately because AI tools can change code very quickly.
A human beginner might slowly break one file. An AI assistant can confidently break nine.
Without Git, your recovery plan is:
- undo;
- hope;
- cry softly;
- ask AI to reverse itself;
- discover the AI does not remember what it did;
- rename the folder and begin a new era of denial.
With Git, your recovery plan can be:
git status
git diff
git restore path/to/file
Or, if things are worse:
git reset --hard
That last command is powerful and destructive to uncommitted work, so do not treat it like a snack.
But when used correctly, Git gives you a way back.
The cave has a rope.
The core Git commands for vibe coders
git init — start tracking a project
git init
This turns your current folder into a Git repository.
It creates a hidden .git folder that stores history.
Do not delete .git unless you intentionally want to remove the project history.
That folder is the memory.
Deleting it is software amnesia with extra steps.
git status — ask what changed
git status
This shows the current state of your working directory and staging area.
GitHub’s own Git guide says git status only outputs information and does not modify commits or changes.
That makes it one of the safest commands to run when you feel lost.
When in doubt:
git status
The command is not glamorous.
It is reliable.
Like a flashlight with emotional boundaries.
git add . — stage changes
git add .
This stages all current changes for the next commit.
Think of staging as saying:
These are the changes I intend to save.
For more control, stage one file:
git add src/App.tsx
Vibe coders often use git add . because it is fast.
That is fine for small projects, but before using it, run:
git status
Make sure the AI did not change a file you did not expect.
The goblin may have wandered.
git commit — save a checkpoint
git commit -m "working version before adding export"
A commit saves the staged changes into project history.
Write messages that future-you can understand.
Bad commit message:
git commit -m "stuff"
Better:
git commit -m "add CSV upload and preview table"
Best for vibe coding:
git commit -m "working CSV upload before AI refactor"
There is dignity in warning future-you.
git diff — see the exact changes
git diff
git diff shows line-by-line changes.
The official Git book explains that git diff helps answer what has changed but not yet been staged, and git diff --staged shows what is staged for the next commit.
For vibe coders, this is one of the most important commands.
AI tools often say:
I made a small change.
Git diff says:
It touched the login flow, deleted two validation checks, and renamed a function for no reason.
Believe the diff.
The diff has no need to impress you.
git log — see history
git log --oneline
This shows recent commits.
Useful when you need to find the last version that worked.
Your project history becomes a trail of breadcrumbs.
Not all breadcrumbs lead home. Some lead to technical debt.
But they are better than darkness.
git restore — restore a file
git restore src/App.tsx
This restores a file from the last commit, discarding uncommitted changes in that file.
Use carefully.
This is helpful when AI changes one file badly and you want to undo it.
Ask AI first:
If I run
git restore src/App.tsx, what will happen? Will I lose uncommitted work?
Make it explain.
The machine should earn the command.
A vibe coding Git workflow that actually works
Step 1: Start the project
git init
git status
Create a .gitignore file before committing.
At minimum, avoid committing:
node_modules/
.env
dist/
build/
__pycache__/
The .env line matters.
Secrets do not belong in Git.
Secrets in Git become secrets in public, which means they are no longer secrets. They are confessions.
Step 2: Commit the first working version
After the basic app runs:
git add .
git commit -m "initial working app"
Do not wait for perfection.
Commit when it works.
A working ugly app is a checkpoint. A beautiful broken app is a haunted painting.
Step 3: Before asking AI for a big change, commit
Before prompts like these:
- “refactor this app”;
- “add authentication”;
- “connect database”;
- “move to a new architecture”;
- “improve the UI everywhere”;
- “fix all errors.”
Run:
git status
git add .
git commit -m "working version before major AI change"
Yes, the message is dramatic.
So is losing three hours.
Step 4: Ask AI to list files before editing
Prompt:
Before changing code, list the files you intend to edit and explain why. Do not modify anything yet.
This gives you a preview of the blast radius.
If the AI wants to edit two files for a two-file problem, fine.
If it wants to edit seventeen files and your refrigerator firmware, pause.
Step 5: Review changes
After AI edits:
git status
git diff
Look for:
- unexpected deleted files;
- new packages;
- changed authentication;
- modified environment handling;
- removed validation;
- suspicious “temporary” comments;
- broad rewrites.
You do not need to understand everything immediately.
You need to notice when the story changed.
Step 6: Test before committing
Run the app. Click the feature. Reload the page. Try bad input. Check the terminal.
Then commit:
git add .
git commit -m "add export button"
Commit after testing.
A commit is not a wish. It is a record.
Try not to record the cursed version as the official family portrait.
Branches: the experiment cage
A Git branch lets you try changes without disturbing the main line of work.
Create a branch:
git checkout -b add-login
Now experiments happen on add-login.
If things go well, you can merge later. If things go badly, you can leave the branch in the woods.
Branches are useful for AI prompts like:
- add login;
- redesign dashboard;
- move from local storage to database;
- add payments;
- refactor components;
- test a new package.
These are not tiny changes.
They deserve a cage.
Beginner branch rule
Use a branch when the AI might edit more than three files.
That rule is not scientific.
It is Bongbetic folklore.
Bongbetic folklore has saved keyboards.
Commands that need caution
Some Git commands are powerful.
Powerful is not bad.
Powerful means “read before drinking.”
git reset --hard
This discards uncommitted changes and resets the project to the last commit.
Useful when the project is a smoking crater. Dangerous if you have uncommitted work you wanted to keep.
Before running it, ask:
What uncommitted work will I lose if I run
git reset --hard?
Then run:
git status
Check first.
git clean -fd
This removes untracked files and directories.
That can delete files Git is not tracking yet.
Maybe those files are junk. Maybe those files are your entire new feature.
Do not run this casually.
git push --force
This can rewrite remote history.
If you are working alone, it can still cause confusion. If you are working with others, it can cause the kind of silence in Slack that means someone has stood up from their chair.
Do not let an agent run force commands unless you know exactly why.
Git prompts for AI-assisted coding
Before changes
Check Git status and tell me whether I should commit before making this change. Do not modify files yet.
After changes
Summarize the diff in plain English. List every file changed and whether the change was expected.
Before rollback
I want to undo the last AI-generated change. Explain whether I should use
git restore,git reset, or a new revert commit. Ask me to confirm before destructive commands.
For commit messages
Generate a clear Git commit message based on this diff. Use practical language, not hype.
AI can help you use Git.
Do not let AI hide Git from you.
Git is not paperwork. It is memory.
Final thought
Git is not the opposite of vibe coding.
Git is what makes vibe coding less terrifying.
The faster AI helps you move, the more you need checkpoints.
A project without Git is a tightrope with no net. A vibe-coded project without Git is a tightrope with a cheerful robot shaking the pole.
Save often. Inspect diffs. Branch experiments. Commit working versions.
When the AI gets creative, make sure you can go home.
Next step
Tie the rope before entering the cave.
FAQs
Do I need Git for vibe coding?
Yes. Git helps you save working versions, inspect AI-generated changes, undo mistakes, and experiment safely.
What Git command should beginners use most?
Start with git status. It tells you what changed and does not modify your project.
Should I commit before every AI change?
Commit before any major AI change, especially refactors, database work, authentication, dependency updates, or multi-file edits.
What is git diff for?
git diff shows exact line-by-line changes. It is useful for reviewing what an AI assistant changed before you accept or commit it.
Are Git commands dangerous?
Some are safe and informational, such as git status. Others, like git reset --hard, git clean -fd, and git push --force, can discard work or rewrite history. Use them carefully.