Skip to content

Module 1: Why Version Control + What is Git?

🎯 What you'll learn: Why version control exists, what problem it solves, and what Git actually is.

The Problem — File Chaos 📁

Have you ever done this?

📁 My Project/
├── report.docx
├── report-v2.docx
├── report-v2-final.docx
├── report-v2-FINAL-real.docx
├── report-v2-FINAL-real-UPDATED.docx
└── report-v2-FINAL-real-UPDATED-use-this-one.docx

Or maybe this:

📁 Website Files/
├── index.html
├── index-backup.html
├── index-old.html
├── index-new.html
├── index-broken-dont-touch.html
└── index-working-march-26.html

We've all been there. You make a change, something breaks, and you don't know which version was the "good" one. You're afraid to delete anything because you might need to go back.

This is the file chaos problem — and it gets worse when:

  • Multiple people are editing the same files
  • You need to go back in time to see what changed
  • You want to experiment without risking the working version
  • You need to know who changed what and when

The real cost

In a professional environment, file chaos leads to lost work, broken deployments, and "it was working yesterday!" panic. Version control eliminates all of this.

The Analogy — Three Levels of "Undo" ⏪

You already know version control — you just don't call it that:

Level 1: Ctrl+Z (Undo)

In Word or any app, Ctrl+Z undoes your last action. Simple. But it only goes back a few steps, and when you close the file, the undo history is gone forever.

Level 2: Track Changes (Word)

Word's Track Changes shows you every edit — who changed what, when. You can accept or reject changes. Better! But it only works within that one document.

Level 3: Git — Time Machine for Your Entire Project ⭐

Git is like Track Changes, but for every file in your project, with unlimited undo history that never goes away. You can:

  • Go back to any point in time
  • See exactly what changed, line by line
  • Create parallel "what if" versions
  • Work with a team without overwriting each other's work
Feature Ctrl+Z Track Changes Git
Undo changes ✅ ✅ ✅
See who changed what ❌ ✅ ✅
History survives closing the file ❌ ✅ ✅
Works across multiple files ❌ ❌ ✅
Unlimited history forever ❌ ❌ ✅
Parallel versions (branches) ❌ ❌ ✅
Works offline ✅ ✅ ✅

💡 Git is the ultimate Ctrl+Z — for your entire project, forever, across all files, with full history of who did what.

What is Version Control?

Version control is a system that records changes to files over time, so you can recall specific versions later.

Think of it like a save game in a video game:

  • Every time you reach a milestone, you save your progress
  • If you mess up, you load a previous save
  • You can have multiple save slots (different paths/experiments)
  • The save file remembers everything — your position, inventory, progress

In version control terms:

Video Game Git
Save your progress Make a commit
Load a previous save Go back to a previous commit
Multiple save slots Different branches
Save file stores everything Repository stores full history

What is Git?

Git is a version control system — a free, open-source tool that tracks changes to your files and lets you collaborate with others.

Fact Detail
What it is A free, open-source version control tool
Who made it Linus Torvalds (the creator of Linux)
When 2005 — over 20 years ago!
Where it runs On your computer (it's a local tool)
How you use it Through the command line (or visual tools)
What it tracks Any text-based files (code, config, markdown, HTML)
Cost Free, forever

Git is NOT GitHub

Git is the tool that runs on your computer. GitHub is a website where you store and share Git repositories. We'll cover this distinction properly in Module 4. For now, just remember: Git = the engine, GitHub = the garage where you park it.

A Brief History — Why Git Was Created 📖

In 2005, Linus Torvalds (the creator of Linux) had a problem:

  • The Linux kernel had thousands of developers worldwide
  • They needed to track millions of lines of code
  • The tool they were using (BitKeeper) became unavailable
  • Existing alternatives were too slow or didn't work offline

So Linus built his own tool in just 2 weeks. His design goals:

Goal Why It Mattered
⚡ Speed Must handle millions of files instantly
📡 Distributed Every developer gets the full history (works offline!)
🔀 Branching Easy to create parallel versions for experiments
🛡️ Data integrity Impossible to silently corrupt or lose history

He called it Git — which is British slang for a stubborn, annoying person. Linus joked that he names all his projects after himself. 😄

Fun fact

Git became the world's most popular version control system. Today, over 100 million developers use it. If you're working with code — or deploying websites like we do — you're using Git.

Git's Superpower — It's Distributed 🌐

Older version control systems (like SVN) used a centralized model — one master copy on a server, everyone connects to it:

graph TB
    subgraph centralized["❌ Centralized (SVN)"]
        Server["🖥️ Server<br/>(single copy + history)<br/>⚠️ Single point of failure"]
        A1["🧑 Alice<br/>(latest version only)"]
        B1["🧑 Bob<br/>(latest version only)"]
        Y1["🧑 You<br/>(latest version only)"]
        Server --- A1
        Server --- B1
        Server --- Y1
    end

    style centralized fill:#1a0a0a,stroke:#ff4444,color:#fff
    style Server fill:#330000,stroke:#ff6666,color:#fff

Problems: Server goes down? Everyone stops. No internet? No work. Server data lost? Everything is gone.

Git uses a distributed model — every person has a complete copy of the entire project AND its full history:

graph TB
    subgraph distributed["✅ Distributed (Git)"]
        A2["🧑 Alice<br/>Full copy + history"]
        B2["🧑 Bob<br/>Full copy + history"]
        Y2["🧑 You<br/>Full copy + history"]
        GH["☁️ GitHub<br/>(optional shared copy)"]
        A2 <--> GH
        B2 <--> GH
        Y2 <--> GH
    end

    style distributed fill:#0a1a0a,stroke:#44ff44,color:#fff
    style GH fill:#1a1a2e,stroke:#66ffff,color:#fff
Feature Centralized (SVN) Distributed (Git)
Work offline ❌ No ✅ Yes — full history is local
Speed 🐢 Slow (talks to server each time) ⚡ Fast (everything is local)
Server goes down 😱 Everyone stops working 🤷 Nobody notices
Backup copies 1 (the server) As many as there are developers
Internet required ✅ Always ❌ Only when sharing changes

💡 Key insight: With Git, your computer has the complete project history. GitHub is just a convenient place to share it — not a requirement. This is what makes Git so reliable.

What Git Tracks (and What It Doesn't)

Git is designed for text-based files — files where you can see and compare the content line by line:

✅ Great for ❌ Not ideal for
Source code (.js, .py, .cs) Large binary files (videos, .exe)
Configuration files (.json, .yaml) Compiled/build output (.dll, .class)
Documentation (.md, .txt) Databases (.mdb, .sqlite)
HTML / CSS Images (it tracks them, but can't show diffs)
Your Hugo content files! Passwords / secrets! ⚠️

Never commit secrets

Git keeps everything forever in its history. If you accidentally commit a password or API key, it stays in the history even after you delete the file. This is why we use .gitignore (covered in Module 8) — and why your mcp-config.json is backed up to OneDrive, not committed to GitHub.

The Git Vocabulary — 5 Words to Know

Before we move on, here are the 5 most important Git words. Don't worry about memorising them now — they'll make much more sense after the hands-on modules.

Term Plain English Analogy
Repository (repo) A project folder that Git is watching A filing cabinet with a built-in security camera recording every change
Commit A saved snapshot of your project at a point in time A save point in a video game
Branch A parallel copy where you can experiment safely A "what if" timeline in a sci-fi movie
Merge Combining changes from one branch into another Bringing the experiment back to the main timeline
Remote A copy of your repo stored somewhere else (like GitHub) A cloud backup of your filing cabinet

✅ Module 1 Summary

┌─────────────────────────────────────────────────────┐
│                  Module 1 Recap                      │
├─────────────────────────────────────────────────────┤
│                                                      │
│  📁 Problem:  File chaos (v1, v2, v2-FINAL...)     │
│                                                      │
│  💡 Solution: Version control — track every change  │
│               to every file, forever                 │
│                                                      │
│  🔧 Git:     The world's most popular version       │
│               control tool (free, fast, distributed) │
│                                                      │
│  🌐 Key:     Distributed — your machine has the     │
│               FULL history, not just the server      │
│                                                      │
│  📝 5 Words: Repo · Commit · Branch · Merge · Remote│
│                                                      │
│  ⚠️ Note:    Git ≠ GitHub (Module 4 explains this)  │
│                                                      │
│  ➡️ Next:    Module 2 — The Git Mental Model        │
│               (how Git organises your changes)       │
└─────────────────────────────────────────────────────┘

🧪 Module 1 Quiz

Test your understanding! Click each question to reveal the answer.

Q1: What problem does version control solve?

File chaos — the problem of having multiple versions of files (report-v1, report-v2-FINAL) with no way to track what changed, who changed it, or how to go back to a working version.

Q2: Git is centralized — everyone connects to one server. True or false?

False! Git is distributed. Every person has a complete copy of the project AND its full history on their own machine. You can work completely offline, and if a server goes down, nobody loses anything.

Q3: What's the difference between Git and GitHub (in one sentence)?

Git is the version control tool that runs on your computer. GitHub is a website where you store and share Git repositories online. Git is the engine; GitHub is the garage.

Q4: Should you commit passwords or API keys to Git? Why or why not?

Never! Git keeps everything in its history forever — even after you delete the file. Secrets should be stored securely (like in environment variables or encrypted backup) and excluded from Git using .gitignore.

Q5: Name 3 of the 5 key Git vocabulary words and what they mean.

Any 3 of: Repository (project folder Git watches), Commit (saved snapshot), Branch (parallel timeline), Merge (combine branches), Remote (cloud copy on GitHub). We'll explore each one in depth in the upcoming modules!

💬 Discussion — Questions That Came Up

These questions came up during the interactive learning session. They're great questions that many beginners have!

Is Git Already Installed on My Machine?

Quite possibly! Git often comes pre-installed or bundled with other tools. To check, open a terminal and run:

git --version        # Shows the version (e.g., git version 2.53.0)
where.exe git        # Shows where Git is installed

If Git IS installed, you'll see a version number. If not, you'll see an error — in that case, download it from git-scm.com.

Common ways Git gets onto your machine:

Source How
Git for Windows installer Download from git-scm.com
Visual Studio Bundles Git automatically
GitHub Desktop Includes Git
IT department May pre-install on work machines

Don't worry about installation yet

We cover the full installation and setup in Module 3. If Git is already installed, you're ahead of the game!

Can I Open Git and See It? Like SharePoint?

No — Git is invisible! It has no window, no icon on your taskbar, no UI. It's a command-line tool that sits silently on your computer waiting for you to type commands.

SharePoint  →  Open browser, see a website  📊
Word        →  Double-click, see a document 📄
Git         →  No window. No icon. Invisible 👻
              You talk to it by typing commands:
              > git status
              > git commit -m "updated menu"

Analogy: Git is like electricity in your house. You can't see electricity — but you use it every time you flip a switch. Git is the same — always there, tracking your files when you ask it to.

The only evidence Git exists in a project folder is a hidden .git folder:

📁 aguidetocloud-revamp/
├── content/          ← your files (visible)
├── themes/           ← your files (visible)
├── config.toml       ← your files (visible)
└── .git/             ← Git's hidden brain 🧠 (never touch this!)
    ├── objects/      ← all your snapshots/history
    ├── refs/         ← branch pointers
    └── HEAD          ← "which branch am I on?"

There ARE visual tools that give Git a pretty face (covered in Module 3):

Tool Type
GitHub Desktop Windows app — point-and-click Git
VS Code Git panel Built-in Git sidebar
GitKraken / SourceTree Visual branch diagrams
GitHub.com Web view of your repo

What Does "GitHub is Optional" Mean?

Git works fine without GitHub. But should you? Let's compare using a real example — deploying aguidetocloud.com:

With GitHub (your current workflow): 

Your PC  ──git push──>  GitHub  ──Actions──>  Azure SWA (live site)

Without GitHub (direct deploy): 

Your PC  ──swa deploy──>  Azure SWA (live site)

Both work! But here's what you lose without GitHub:

Feature Without GitHub With GitHub
Deploy works? ✅ Yes ✅ Yes
Version history backup? ❌ Only on your PC ✅ On PC AND GitHub
Auto-deploy? ❌ Manual every time ✅ GitHub Actions
Laptop dies? 😱 Everything is gone 😌 Clone from GitHub
Collaborate? ❌ Impossible ✅ Easy
Rollback a bad deploy? 😰 Hard ✅ Revert a commit

⚠️ Real risk: Without GitHub, if your laptop is lost/stolen/broken, your entire website and content history is gone forever. GitHub is your safety net.

Are Local and GitHub Repos Mirror Copies? Is There Primary/Secondary?

After every git push, your local and GitHub repos are identical mirrors:

Your PC (LOCAL)              GitHub (REMOTE)
┌──────────────────┐        ┌──────────────────┐
│ Full project     │ ←————→ │ Full project     │
│ Full history     │  sync  │ Full history     │
│ All branches     │        │ All branches     │
└──────────────────┘        └──────────────────┘

There is no official primary/secondary in Git — all copies are technically equal. But in practice:

  • Your PC = where you work (primary in practice)
  • GitHub = backup + sharing + deploy trigger
  • They're identical after every push
  • They can get out of sync if you forget to push

Phone analogy: Your phone contacts sync to iCloud. Your phone is where you add/edit (primary in practice). iCloud is the backup. If your phone dies, you get a new one and everything syncs back. GitHub works the same way for your code.

Can I Work Entirely on GitHub Without Any Local Copy?

Yes! GitHub offers several ways to work without a local machine:

Method What It Is Cost
Pencil icon ✏️ Edit one file on github.com Free
github.dev Press . on any repo → VS Code in browser Free
GitHub Codespaces Full cloud VM with terminal, Git, all tools Free tier: 60hrs/month

Codespaces is the most powerful — it's a complete development environment in your browser. We cover it in Module 4: What is GitHub?.

For your current learning, working locally is better — you get full control, offline access, and it's free. Cloud-only is great for travelling or quick fixes from any device.

➡️ What's Next?

In Module 2: The Git Mental Model, you'll learn HOW Git actually organises your changes — the three areas (Working Directory → Staging Area → Repository) and what really happens when you run git add and git commit.