What is Git and why do you need it?
Say you make a mistake coding and want to go back to how it was two days ago. If you didn't copy the files separately every day, there's no way to do it. That's why people who work with code use version control software, and the de facto standard is Git. With Git you record the current code safely and can return to that point anytime.
The benefits come down to three. You can roll back to an earlier version after a mistake, you can view the history of what you did and in what order, and you can experiment with new features without fear of breaking the original.
This is exactly where people starting out with vibe coding get stuck before the code itself. AI writes the code for you, but saving it, rolling it back, and branching off to experiment are still your job. The good news is a beginner doesn't need much. A handful of commands gets you going.
How do you install and set it up?
On Windows, download the installer from git-scm.com, run it, and leave the options at their defaults. On Mac, if you have Homebrew, brew install git in the terminal is all it takes. Open the Terminal app on Mac or PowerShell on Windows to run these.
After installing, register who you are just once. Every commit (version record) stores who made it, so think of it as registering an ID. Enter the two lines below one time and you won't have to think about it again.
# Mac (Homebrew): install Git
brew install git
# Windows: download the installer from git-scm.com and run it
# One time: register your identity (recorded in commits)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"add and commit — recording code as versions
First make a working folder and open it in an editor like VS Code. Open a terminal inside that folder and run git init, and from then on Git starts watching the folder. Every change you make here — creating files, writing code — becomes something it tracks.
Now, when you like your code and want to record (back up) this moment, it's two steps. First git add picks the files to record, then git commit stamps that state as a version. When you commit, add a short message after -m saying what you did, e.g. git commit -m "create first file".
Why two steps? Because not every file needs version records. Image files, for instance, barely change in content, so there's no need to record them. So you use add to select only what should be recorded, and commit to finalize it. That middle holding space is called the staging area, and the place where finalized versions accumulate is the repository. The act of adding is called staging.
Three helper commands come up often. git add . stages every changed file at once, git status tells you what's staged and what's modified right now, and git log shows the history of commits you've made. Whenever you're unsure, just run git status.
# Start Git in a working folder (one time)
git init
# Pick files to record (staging)
git add app.txt
# Or stage every changed file at once
git add .
# Finalize as a version (message required)
git commit -m "create first file"
# Check current state / view commit history
git status
git logWhen should you commit?
The most common beginner mistake is committing constantly, as if saving a file. You don't need to. A commit is not the same as a save.
The rule is: when a meaningful chunk is done. Added one small feature? Commit. Modified that feature? Commit again. Recording per unit of work like this makes the history read cleanly later — when you did what. Of course, when you're just practicing alone, don't overthink it; do as you please.
Checking changes — diff and the editor GUI
One good habit: before you commit, take a look at what changed. Comparing the current file against the most recent commit and confirming that only what you intended changed cuts down on mistakes.
In the terminal, git diff shows the difference between the latest commit and your current code. Scroll with space, exit with q. To compare against a specific commit, find the commit ID with git log, then use git diff <commitID>; to see between two commits, git diff <ID1> <ID2>. The catch is that terminal diff shows up narrow in a single pane, so it's hard to read when code is long, and it flags trivial changes like an extra Enter or a space as differences, which is tiring.
So the practical answer is the editor GUI. Open the Source Control tab on the left of VS Code (the leaf-shaped icon) and it shows modified files; the + button stages, the − button unstages, and the check button commits — all in a few clicks. Install an extension like GitLens or Git Graph and it visualizes commit history and changes as a graph, far easier to read. There's no reason to insist on the terminal. Use whichever is comfortable.
# See current changes vs the latest commit (q to quit)
git diff
# Find commit IDs in the history
git log
# Compare a specific commit to now / compare two commits
git diff <commitID>
git diff <ID1> <ID2>
# Open a visual comparison tool
git difftoolbranch — copy off and experiment safely
You're coding and want to add a new feature, but writing it straight into the original makes you nervous — a bad line could cause a bug or break the program. The move is to leave the original safe, make a copy, build the feature there first, and merge it back once it works. That copy is a branch. Think of a branch as a forked copy of the project.
git branch coupon creates a branch called coupon, and git switch coupon moves you onto that copy (the older way is git checkout). The code you were originally working on is itself a branch too, usually called main (or master, depending on the setup). The editor's status bar shows which branch you're on. Files you create on the coupon branch aren't visible when you go back to main — that's how independently you can develop, without touching the original.
To merge, first move to the receiving side (main), then git merge coupon pulls in the copy's work. git log --graph --oneline shows how branches split and joined as a graph, and HEAD means your current position.
One thing to watch is conflicts. If two branches change the same line of the same file differently, Git can't tell which to take, so it stops the merge and reports a conflict. You resolve it by hand — keep only the code you want, delete the rest, and commit. VS Code lets you pick which side's code to apply with buttons, which makes it much easier.
Where branches really shine is collaboration. Ten people editing the same source at once is a disaster. So each person develops on their own branch first and merges when it works. Even practicing alone, create a branch, commit, merge it back, and deliberately cause a conflict to resolve — you'll get the feel fast.
# Create a 'coupon' branch (copy) and switch to it
git branch coupon
git switch coupon # older way: git checkout coupon
# Work on coupon, then add · commit
git add .
git commit -m "add coupon feature"
# Go back to main and merge the copy's work in
git switch main
git merge coupon
# View how branches split as a graph
git log --graph --onelineSo where do you start?
There are only a handful of commands to remember. At first, just run git init once in your working folder and get in the habit of repeating add and commit to keep recording your code. For checking changes (diff) and branches, grasp the concept and start with VS Code's Source Control GUI — that's plenty. You can add terminal commands one at a time once you're comfortable.
The core is simple: the habit of continuously recording your code, and the safety of knowing you can always roll back. When you can roll back, you experiment without fear, and the more you experiment, the better your vibe-coding results get.
This write-up reorganizes 코딩애플's three-part beginner series on Git basics for vibe coding newcomers. Source videos: youtu.be/sly2u8BIi9E (add·commit), youtu.be/xD9GnHKveRk (git diff·editor), youtu.be/XFm2qNs30BE (branch).