Table of Contents
You have probably seen a folder like this: website.html, website-final.html, website-final2.html, website-REAL-final.html. Which one is the latest? Which one works? Nobody knows, not even you.
Version control solves this problem completely. It remembers every change you ever made, lets you go back in time, and lets a whole team work on the same project without overwriting each other. In this guide you will learn how it works, see the commit tree that makes it all click, and practice with real Git commands.
What you will learn (8 minute read):
✓ What version control is, in plain English
✓ How the commit tree, branches and merges work, with a live diagram you can play with
✓ Centralized vs distributed systems
✓ Your first Git commands, with example output
✓ How to fix a merge conflict and avoid common mistakes
What Is Version Control?
Version control is a system that records every change to your project’s files over time. Think of it as a save game system for your code. You can save at any moment, jump back to an earlier save, or try something risky in a separate copy without breaking the main game.
Here is the difference in real life:
e4a91c2 Fix mobile menu bug b7d03f8 Add contact form 3c5e6a1 Improve homepage text a1b2c3d Add homepage
Left: file names pretending to be a history. Right: a real history, with a clear message for every change.
The most popular tool today is Git. Others you may hear about are SVN (Subversion) and Mercurial. Websites like GitHub, GitLab and Bitbucket host your Git projects online so you can share them and work with others.
Why Developers Use It
The Commit Tree
Git stores your project’s history as a tree of commits. A commit is a saved snapshot of your project, and each one points back to the commit before it, like links in a chain. When you create a branch, the chain splits into two paths. When you merge, the paths join back together.
Time flows left to right. Blue is the main branch. Purple is a feature branch that split off, got two commits, and merged back in the filled circle.
The same tree, as Git prints it in your terminal:
git log --oneline --graph --all
* f3a9c21 (HEAD -> main) Merge branch 'feature/contact-form' |\ | * c7d1e4b (feature/contact-form) Add contact form | * 9b2a8f0 Add form styles * | 4e6d7a3 Fix navbar bug |/ * a1b2c3d Add homepage
Example output. Your commit codes (hashes) will be different. The letters and numbers are each commit’s unique ID.
The words you will hear all the time
| Word | Plain-English meaning |
|---|---|
| Repository (repo) | Your project folder plus its full history. |
| Commit | A saved snapshot of your project, with a message describing the change. |
| Branch | A separate line of work. You can experiment safely without touching the main code. |
| Merge | Combining the changes from one branch into another. |
| HEAD | A pointer to where you are right now (the branch and commit you have checked out). |
| Clone | Downloading a full copy of a repository, including its history. |
| Push / Pull | Push sends your commits to the online copy. Pull brings other people’s commits to you. |
| Pull request (PR) | A request to merge your branch, so teammates can review it first. |
| Conflict | When two people changed the same lines and Git needs you to choose. |
Build Your Own Commit Tree
Play with the tree below. Add commits, create a branch, make commits on it, then merge it into main. Click a branch name to switch to it. The yellow ring shows where you are (HEAD), and the Git command for each action appears underneath.
# Click a button aboveTwo Types of Version Control Systems
Version control systems come in two main designs. The difference is where the full history lives.
One server holds the history. If it goes down, nobody can save their work. Example: SVN
Everyone has the full history, so you can work offline and commit locally. Examples: Git, Mercurial
| Centralized (SVN) | Distributed (Git) | |
|---|---|---|
| Where is the history? | On the central server | On every developer’s computer |
| Work offline? | Limited | Yes, commit locally anytime |
| Branching and merging | Possible, but heavier | Fast and lightweight |
| If the server fails | Work stops until it is back | Anyone’s copy can restore it |
| Easy to start? | Simple model | A few more concepts to learn |
Your First 10 Minutes with Git
Let’s go from zero to a merged feature. Install Git first, then open a terminal. The outputs below are examples, so your commit codes will differ.
STEP 1Set up your name (one time only)
git config --global user.name "Your Name" git config --global user.email "you@example.com"
Create a repository
mkdir my-site cd my-site git init -b main
Initialized empty Git repository in /home/you/my-site/.git/
Make your first commit
Create a file called index.html (anything is fine), then check what Git sees:
git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
Git sees the file but is not tracking it yet. Add it to the “staging area”, then commit:
git add index.html git commit -m "Add homepage"
[main (root-commit) a1b2c3d] Add homepage
1 file changed, 10 insertions(+)
create mode 100644 index.html
Why two steps (add, then commit)? The staging area lets you choose exactly which changes go into each commit. You can change five files but commit only two of them, keeping your history neat.
See your history
git log --oneline
3c5e6a1 (HEAD -> main) Improve homepage text a1b2c3d Add homepage
Work safely on a branch
Let’s build a contact form without touching main. Create a branch, make some changes, and commit them:
git switch -c feature/contact-form
# ...edit your files, then:
git add .
git commit -m "Add contact form"
Switched to a new branch 'feature/contact-form' [feature/contact-form 9b2a8f0] Add contact form 1 file changed, 12 insertions(+)
Merge it back into main
The form works, so bring it into main:
git switch main git merge feature/contact-form
Switched to branch 'main' Updating 3c5e6a1..9b2a8f0 Fast-forward contact.html | 12 ++++++++++++ 1 file changed, 12 insertions(+)
“Fast-forward” means main had no new commits, so Git simply moved it forward. If both branches had new work, Git would create a merge commit instead.
STEP 7Undo a mistake the safe way
If a commit caused a problem, git revert adds a new commit that undoes it. Your history stays intact, which is safe even on shared projects.
git revert 9b2a8f0
[main d4e5f6a] Revert "Add contact form"
1 file changed, 12 deletions(-)
Careful with git reset --hard and git push --force. They can permanently throw away work, and on shared branches they can erase other people’s commits. As a beginner, prefer git revert.
Put it on GitHub
Create an empty repository on GitHub, then connect it and push (replace the address with your own):
git remote add origin https://github.com/your-username/my-site.git git push -u origin main
From now on, git push sends your new commits and git pull brings down your teammates’ work.
Code Review with Pull Requests
On a team, you do not merge straight into main. You open a pull request on GitHub, GitLab or Bitbucket. Teammates see exactly which lines changed (green is added, red is removed), leave comments, and approve it before it is merged.
required attribute to the email field.A pull request (illustration). Real screenshots of your own GitHub page work great here.
Fixing a Merge Conflict
A conflict happens when two branches changed the same line, and Git cannot decide which one to keep. It is not an error, and it is not scary. Git simply asks you to choose.
$ git merge feature/new-title
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Open the file. Git marks both versions for you:
<<<<<<< HEAD <h1>Welcome to My Site</h1> ======= <h1>Hello and Welcome!</h1> >>>>>>> feature/new-title
<<<<<<<, =======, >>>>>>>).git add index.html, then git commit.Good Habits for Clean Version Control
Write commit messages your future self will thank you for
| Avoid | Better |
|---|---|
| update | Fix mobile menu not closing on tap |
| fix stuff | Add email validation to contact form |
| final | Compress hero image to speed up homepage |
| asdf | Remove unused CSS from the blog template |
Tell Git what to ignore
Some files should never be in your history: secret keys, downloaded packages, system junk. Create a file named .gitignore in your project folder:
node_modules/ .env .DS_Store dist/ *.log
Never commit passwords or API keys. Git remembers everything, so a secret that was committed once stays in the history even after you delete the file. If it happens, change that password or key right away.
Using WordPress? You can keep your custom theme or plugin in Git. Do not commit wp-config.php (it holds your database password) or the wp-content/uploads folder. Add them to .gitignore.
Popular Version Control Tools
| Tool | Type | Good to know |
|---|---|---|
| Git | Distributed | The industry standard. Fast, flexible, with powerful branching. |
| Subversion (SVN) | Centralized | Simple and still found in older projects. |
| Mercurial | Distributed | Known for a clean, easy-to-use design. |
| Perforce (Helix Core) | Centralized | Built for very large codebases and big files. |
| TFVC | Centralized | Microsoft’s older system. Most teams now choose Git. |
| Darcs | Distributed | Uses a unique patch-based approach. |
Where to host your Git projects
Common Mistakes Beginners Make
| Mistake | Fix |
|---|---|
| Working directly on main | Create a branch for every feature or fix. |
| Committing secrets or node_modules | Add them to .gitignore from day one. |
| Huge commits with vague messages | Commit small, and describe what changed and why. |
| “git add .” without looking | Run git status first so nothing unwanted slips in. |
| Push rejected | Run git pull to get others’ work, fix any conflicts, then push again. |
| Using force commands to fix problems | Prefer git revert. Ask for help before using --force. |
Where Version Control Is Heading
The basics of Git have stayed steady for years, but the tools around it keep improving. Expect more of these:
Common Questions
What is the difference between Git and GitHub?
Git is the tool that tracks your changes on your own computer. GitHub is a website that hosts Git repositories online so you can share and collaborate. You can use Git without GitHub, but not GitHub without Git.
Do I need version control if I work alone?
Yes. It is your safety net. You can try bold ideas, undo mistakes and see how your project grew. Many solo developers say they would never go back.
Is Git hard to learn?
The daily basics are just a handful of commands: status, add, commit, switch, merge, push and pull. Practice them on a small project and the rest follows.
Is SVN obsolete?
Not completely. Some organizations still use it, especially for older projects. But for new projects, most teams choose Git because of its speed, flexible branching and huge ecosystem.
Can I use Git for non-code files?
Yes, Git works best with text files like code, but you can also track documents and configuration. Very large binary files (videos, big design files) are better handled with special tools such as Git LFS.
Want to go deeper? Read our next article, What do you mean by Git?, for a closer look at the tool itself.
Final Thoughts
Version control turns your project from a pile of “final_v2” files into a clear, safe history. Remember the tree: commits are snapshots, branches are safe side paths, and merges bring the good work back together.
Open a terminal, run git init on any small project, and make your first commit today. Then tell me in the comments how it went. I read every comment.
If this guide helped you, share it with a friend who is learning to code. Thank you for reading!
