Loading...
Loading...
Guides, templates, and tools for developers
Lost 3 days of work because of AI? Git is your insurance against 'everything broke and can't be fixed'. A simple Git guide for those who vibecode.
Lost 3 days of work because Cursor decided your code was trash? Claude Agent accidentally deleted half your project, and you don't know how to bring it back?
Sound familiar? Then buckle up. Today we're saving your projects from disappearing.
Hey there, vibecoders! If you're still not using Git in your projects, then make sure to read this article to the end or save it to bookmarks, because this will save your project.
As usual: I bring you quality content, you bring me likes and subscriptions. Let's get started.
Imagine: you built a cool feature in your project, everything works. You decide to add one more small thing — and boom, everything breaks. And you didn't save the working version.
Git solves this problem once and for all.
Git is a time machine for your code. With it, you can save every change in your project. Git will store a sequential history of all changes. Something went wrong, AI deleted half your code? No problem — we just roll back to the state we need.
1. Protection from Rogue Agents
AI can screw up, break something, delete necessary code, or fix it in a way that it won't work. Git allows you to quickly and easily return to the state that was working.
2. Experiments Without Fear
Want to try implementing a feature but not sure if it'll work out, and afraid of breaking working code? No problem — create a separate branch, work in it, test. Everything's good — merge. Something didn't work out — return to the working branch.
3. Cloud Backup
Thanks to services like GitHub, GitLab, or Bitbucket, we can store our projects along with change history in the cloud. Roughly speaking, it's like Google Drive, but with change history. And if, God forbid, something happens to your laptop or computer, you can easily restore the project from this cloud.
In short: Git for vibecoders is the "Undo Changes" button on steroids, which gives us flexible and simple version control of our project.
If it seems complicated and unclear right now, don't worry. I'll explain everything in detail with examples of how it works.
To understand how Git works, we need to know three main terms.
Commit — is a record of changes. You make some change, commit it, and this change is saved in Git's change history. And such a record of changes is called a commit.
Make one change — committed. Make a second change — committed. This way, we form a change history from which the final state of the project is composed.
If at some point something breaks, we can easily roll back to some commit in this chain of changes where everything was working.
Each commit includes:
Best practice: Commit often, with clear messages. Future you will say thanks.
Rolling back through commits is possible, but it's not always convenient. So let's look at the second term — branches.
Branches — are like parallel histories of commits. First, we'll have one main branch. Usually it's called main or master. If desired, you can name it differently, but it's better to use established names.
Why it's needed:
Suppose we were making some changes, committing it all to the main branch. Some history of these changes formed there. And now we have a working version of the project, and this state is in the main branch.
And then we wanted to implement some new features or maybe just experiment with some functionality. It's far from certain that everything will work right away, especially if a large volume of work is expected. But it would be convenient for us to save intermediate changes on the way to implementing this new functionality.
But if we commit changes to our main main branch, there's a high chance we'll break the working version of the project. To avoid this, we create a new branch — so to speak, a parallel development history.
When creating a branch, initially it will be completely identical to our main main branch. Then we'll commit our changes to the new branch, and the main branch will remain as it was.
When we finish developing our new functionality and test that everything works, we'll merge our changes from the second branch into our main branch. New changes will appear in our main branch, and we'll be confident that everything works correctly.
Merging branches is called merge. We'll look at this process with examples later.
If we break something in the process of implementing new functionality or our experiment suddenly fails, we'll simply return to our main branch where everything works. We'll continue project development from the working state, and we can simply delete the branch where something didn't work out.
The third term we need to know is repository.
Simply put, Git repository is a folder with project files and change history.
There are:
Speaking of local repository, essentially your project folder after initializing Git in it becomes a repository. A .git folder appears in the root of your project, and it stores all the change history: branches, commits, and so on.
Speaking of remote repository, for simplicity it can be perceived as cloud storage. Like Google Drive, but it also stores the history of all your changes.
The most popular services for storing Git repositories are GitHub, GitLab, Bitbucket, and there are others. You can basically choose the one you like more.
Remote repositories are very practical to use. As I already said, if, God forbid, something happens to your computer or project or hard drive, you can always download the current version from the remote Git repository.
Additionally, using a remote Git repository, you can work on one project together with other developers. Without Git, collaborative work on one project will turn into hell.
Remember these commands — and you can already work:
# 1. Check status - what changed
git status
# 2. Add files to staging area
git add .
# 3. Make a commit (save changes)
git commit -m "Added contact page"
# 4. Push to GitHub
git push
# 5. Get updates from GitHub
git pull
That's it. Seriously. These five commands are enough for 90% of your work.
Two ways:
Option 1: Create a repo from an existing folder
cd your-project
git init
Option 2: Download someone else's project from GitHub
git clone https://github.com/username/project.git
Before the first commit, you need to introduce yourself:
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
This is done once, then Git will remember.
Worked on the project, everything works — save it:
git status # see what changed
git add . # add all files
git commit -m "Made registration form"
git push # send to GitHub
When to use: At the end of a working session, after each completed feature.
Broke something and want to go back?
Suppose you're working with a project, deleted some necessary code, something broke, in general, it doesn't work, and you didn't commit these changes — that is, they're only local. And in the last commit in the branch everything worked fine, and you want to roll back.
In VS Code it's simple:
Go to the Git work section, select the file we want to roll back, and there's a Discard Changes button. Click it, confirm, and our file is restored to the state it was in at the last commit.
Through command line:
# Undo changes in a file (if you haven't done add yet)
git checkout -- filename.txt
# View commit history
git log --oneline
# Return to a specific commit
git checkout abc123
Life hack: Before risky experiments, make a commit with the message "backup before experiment".
Want to try a new idea but not sure if it'll work out?
# Create a branch for the experiment
git switch -c experiment-animations
# Work, make commits
git add .
git commit -m "Tried animations"
# If you liked it - merge into main
git switch main
git merge experiment-animations
# If you didn't like it - just delete the branch
git branch -d experiment-animations
The beauty is that main remains untouched until you decide to merge the changes.
GitHub is cloud storage for your repositories plus a social network for developers.
What it gives:
# 1. Create a repository on github.com (through web interface)
# 2. Connect local project
git remote add origin https://github.com/username/project.git
# 3. Upload code
git push -u origin main
Found a cool project, want to poke around or suggest an improvement?
# 1. Click "Fork" on GitHub - your copy is created
# 2. Clone it to yourself
git clone https://github.com/your-username/project.git
# 3. Make changes
git add .
git commit -m "Fixed validation bug"
git push
# 4. Create a Pull Request through GitHub
Pull Request is a proposal to the author to accept your edits. A polite way to say "I improved your code".
Bad:
git commit -m "fix"
git commit -m "asdf"
git commit -m "works"
Good:
git commit -m "Fixed email validation bug"
git commit -m "Added animation for login button"
git commit -m "Updated dependencies to latest versions"
Rule: The message answers the question "What was done?". Write for your future self.
Don't commit temporary files, logs, passwords!
Create a .gitignore file in the project root:
node_modules/
.env
*.log
.DS_Store
dist/
Now Git ignores these files.
If you're working with a remote repository, always:
git pull # first get changes
# work
git push # then send yours
Habit: Start your workday with git pull.
Experimenting directly in main → breaking working code → sadness.
Solution: Create branches for new features.
git switch -c add-user-profile
# work
git switch main
git merge add-user-profile
See this and panic?
CONFLICT (content): Merge conflict in index.html
Don't panic. Open the file, find:
<<<<<<< HEAD
your code
=======
friend's code
>>>>>>> branch-name
Choose the needed option (or combine), delete markers, save:
git add .
git commit -m "Resolved conflict"
Life hack: VS Code highlights conflicts and gives "Accept Current" / "Accept Incoming" buttons.
VERY DANGEROUS:
const API_KEY = "sk-1234567890abcdef"; // NEVER DO THIS
Correct:
.env file:API_KEY=sk-1234567890abcdef
Add .env to .gitignore
Use environment variables:
const API_KEY = process.env.API_KEY;
If you already committed: Regenerate the API key immediately. It's already compromised.
Set up once:
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.cm commit
git config --global alias.br branch
Now:
git st # instead of git status
git co # instead of git checkout
# Compact view of history
git log --oneline
# Last 5 commits
git log --oneline -5
# Branch graph (beautiful!)
git log --oneline --graph --all
Don't like command line? There's a graphical interface:
desktop.github.comGood enough for vibecoding.
Made a site with HTML/CSS/JS? Host it for free:
main branchusername.github.io/projectPerfect for portfolio.
One of the coolest moments is that you can ask your AI agent to do all these commands for you.
For example, if you're working with a project, deleted some necessary code, something broke, you can simply write to the agent:
Roll back to commit with ID abc123 and push to remote repository
And the agent will execute the necessary commands. It can suggest git reset --hard for local rollback, and then git push origin main --force-with-lease to send to the remote repository.
Important point: the --force-with-lease parameter is safer than just --force, because it applies force only if the remote branch is in the same state we last downloaded it.
But it's not very convenient to play with commits like that. And it's much simpler to switch between branches — for some new feature create a new branch, develop the new feature there, when we've done it, merge into the main branch. Or switch to the main branch and delete the side branch if we don't want to develop it anymore.
Working Directory → git add → Staging Area → git commit → Local Repo → git push → GitHub
(your files) (preparation) (history) (cloud)
In simple words:
git add moves changes to Staging Area (staging area)git commit saves snapshot in Local Repository (local history)git push sends to GitHub (cloud)Git is not that complicated, especially when you have an AI agent at hand that can execute all complex commands and resolve conflicts.
But using Git gives you confidence that you won't lose your project. Even if you screwed up somewhere, you still have this change history, and one way or another you'll be able to roll back to the stage you need, when everything was working correctly and nothing was broken yet.
Moreover, if you store your project in a remote repository, you'll be able to download it to any other computer, work collaboratively with other people, and be confident that even if something happens to your computer, you have the project in the remote repository, which you can always restore from it.
For vibecoders, Git is insurance and a superpower.
Yes, you can roll back within the context of one chat in Claude, in Cursor, in some other services, but that's just the context of one chat. But as soon as you create a new chat, the change history disappears, so you need Git. And with neural networks, this is simply a must-have, there's no way without it.
Start with simple:
git init)These five steps — and you're already using Git like a pro.
Main thing: Don't try to memorize all commands at once. Start with the basic five, the rest will come with practice.
You'll enjoy it when you roll back broken code with one command for the first time 😉
In short, quality content! I hope I managed to explain in an accessible and simple way how you can use Git in your vibecoding projects.
If you still have questions, write them in the comments. Or ask your AI agent.
Subscribe to the channel so you don't miss new videos. Like it so YouTube recommends you more quality content.
Subscribe to the Telegram channel "Quality Vibecoding". In it, I publish useful materials about vibecoding. We also have a vibecoder chat, where you can chat with other vibecoders, ask questions, answer answers. Sometimes they even publish some offers about vibecoding projects there.
So join our vibecoding community!
Useful resources:
And with that, I say goodbye. Quality code to everyone and see you soon!