What Is Version Control and Why Every Builder Needs Git

You are building a website. It works. The homepage loads, the menu looks right, and the contact form sends emails. Then you decide to add a new feature: a product gallery. You start changing files. You move some code around. You update the CSS. You add new JavaScript.

Three hours later, the gallery works but the contact form is broken. You try to fix it. Now the homepage layout is wrong. You press Ctrl+Z but you have made too many changes across too many files. You cannot remember what the code looked like before you started. You are stuck.

Without version control, your options are:

• Spend hours trying to manually reverse your changes (error-prone and frustrating).
• Hope you saved a backup copy of the entire project folder somewhere (you probably did not).
• Start over from your last manual backup, which was three days ago (losing all the work you did in between).

Now imagine the same scenario with Git. Before starting the gallery feature, you committed your working code. Every change you made since then is tracked. When things break, you type one command and your code is back to the exact state it was in before you started. Three hours of broken changes, undone in 5 seconds. Then you can start the gallery feature again, more carefully this time.

That is version control. It is a safety net for your code. Every save point (commit) is a snapshot you can return to. You can experiment freely because you know you can always go back.

Git works by taking snapshots of your project at moments you choose. These snapshots are called commits. Each commit records exactly what every file in your project looked like at that moment, plus a message you write describing what changed.

Your project's history becomes a timeline of commits:

Commit 1: "Initial project setup with homepage"
Commit 2: "Added contact form with email sending"
Commit 3: "Fixed contact form validation bug"
Commit 4: "Added product gallery page"
Commit 5: "Fixed gallery layout on mobile phones"

If commit 4 introduced a bug, you can see exactly what changed between commit 3 (working) and commit 4 (broken). You can even go back to commit 3 temporarily to confirm that the bug did not exist before your gallery changes.

Git tracks changes, not entire files. When you commit, Git does not copy every file. It records only what changed: which lines were added, removed, or modified. This makes Git fast and efficient even for large projects with thousands of files.

Git works locally. Git runs on your computer. You do not need internet to make commits, view history, or switch between versions. Your entire project history is stored in a hidden .git folder inside your project directory. You only need internet when you want to share your code with others (pushing to GitHub).

Commits are permanent. Once you commit, that snapshot exists in your history. Even if you make 10 more commits, you can still go back to any previous commit. This permanence is what makes Git a reliable safety net. You cannot accidentally lose a committed version of your code.

Git has many commands, but you will use the same handful daily. Here are the essential ones.

git init creates a new Git repository in your project folder. You run this once when starting a new project. It creates the .git folder that stores your project's history.

git status shows you what has changed since your last commit. Which files are modified? Which are new? Which are staged for the next commit? Run this frequently. It is your "where am I?" command.

git add stages changes for the next commit. Think of it as selecting which changes to include in your next save point. git add index.html stages one file. git add . stages everything that changed. You stage before you commit because sometimes you want to commit only some of your changes, not all of them.

git commit -m "your message" creates the snapshot. The message should describe what changed and why. Good messages: "Added M-Pesa payment callback handler." "Fixed phone number validation bug." Bad messages: "Updated stuff." "Fix." Good commit messages help you (and your teammates) understand the project's history months later.

git log shows the history of commits. Each entry shows who made the commit, when, and the message. Useful for finding when a bug was introduced or understanding what changes were made recently.

git push sends your local commits to a remote repository (like GitHub). This is how you share your code with your team and back it up online.

git pull downloads commits from the remote repository that others have pushed. This is how you get your teammate's latest changes.

Those seven commands cover 90% of your daily Git usage. The remaining 10% (branching, merging, resolving conflicts) you will learn as you work in teams.

Branches are Git's answer to "I want to try something without risking the working code."

Think of branches as parallel timelines. Your main branch (usually called main) is the stable, working version of your code. When you want to add a new feature, you create a new branch. This branch starts as an exact copy of main but diverges as you make changes. Your main branch stays untouched while you experiment on the feature branch.

main:    A -- B -- C
                    \
feature:             D -- E -- F

Commits A, B, C are on main. Commits D, E, F are on the feature branch. The feature branch has everything from main (A, B, C) plus its own changes (D, E, F). Main does not have D, E, or F yet.

When the feature is done and tested, you merge the feature branch into main. Now main has everything: A, B, C, D, E, F. If the feature did not work out, you delete the branch and main is completely unaffected.

Why this matters for teams: Three developers can work on three different features simultaneously, each on their own branch. Developer A adds a payment feature. Developer B redesigns the homepage. Developer C fixes a bug in the login flow. None of them interfere with each other. When each feature is ready, they merge their branch into main, one at a time.

The commands:

git branch feature-payments    # Create a new branch
git checkout feature-payments   # Switch to that branch
# ... make changes, commit ...
git checkout main               # Switch back to main
git merge feature-payments      # Merge the feature into main

Branching and merging is where Git's real power lives. It allows safe experimentation and parallel work. Once you are comfortable with branches, you can work fearlessly because you always have a clean main branch to fall back to.

Git is the tool. GitHub is the platform. Git runs on your computer. GitHub is a website where you store your Git repositories online. Think of Git as your word processor and GitHub as Google Drive. You write locally, you store and share online.

What GitHub gives you:

• Backup. If your laptop is stolen or your hard drive dies, your code is safe on GitHub. Every commit, every branch, every version of your project.
• Collaboration. Team members push and pull code through GitHub. Pull requests (PRs) let you propose changes, discuss them, and get feedback before merging into main. Code reviews happen on GitHub.
• Portfolio. Your GitHub profile is your developer portfolio. Employers look at it. Having active repositories with good code, clear READMEs, and meaningful commit history demonstrates that you can build things. An empty GitHub profile suggests you are not building.
• Open source. Millions of open source projects live on GitHub. You can read their code, report bugs, and contribute improvements. Contributing to open source is one of the best ways to learn from experienced developers.

Setting up GitHub:

1. Create a free account at github.com.
2. Create a new repository (the GitHub term for a project).
3. Connect your local Git project to the GitHub repository: git remote add origin https://github.com/yourusername/yourproject.git
4. Push your code: git push -u origin main

From now on, every time you commit locally and push, your code on GitHub updates. Your project is backed up, visible, and shareable.

Git is not an optional skill. It is assumed. Every software company, from Safaricom to a 3-person startup, uses Git. If you show up to a job interview and do not know Git, the interview is effectively over.

Why it is non-negotiable:

Teams cannot function without version control. When 5 developers work on the same codebase, they need a system to merge their changes, track who changed what, and resolve conflicts when two people modify the same file. Git is that system. There is no alternative in common professional use.

Code reviews depend on Git. Modern teams do not push code directly to the main branch. They create branches, open pull requests, and have teammates review the code before merging. This process catches bugs, shares knowledge, and improves code quality. It all runs through Git and GitHub.

Deployment depends on Git. Many companies deploy new code by pushing to a specific Git branch. Push to the "production" branch and the live website updates automatically. This is called CI/CD (Continuous Integration/Continuous Deployment), and it is built on top of Git.

How to build your Git skills:

• Use Git for every project you build, even personal ones. Make it a habit.
• Write clear commit messages. "Added user registration with phone number OTP" is useful. "Updates" is not.
• Push to GitHub regularly. Build your public profile.
• Practice branching. Even on solo projects, create a branch for each feature and merge it when done. This builds the muscle memory you need for team work.

Our Full-Stack Software and AI Engineering course (KES 120,000) uses Git and GitHub from day one. Every project, every assignment, every code review goes through Git. By the end, Git feels as natural as typing.