<aside> 🔀
Module 1 — Why Version Control, and What Git Actually Is (git config). Every Git command you will ever run makes sense only if you know what problem Git solves and what kind of machine it is. This module builds that mental model — it is the difference between memorizing commands and deriving them.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. This is the first module — no earlier modules are needed, and no Git knowledge is assumed. You need: a Linux machine (or macOS, or WSL on Windows), a terminal, and the ability to type commands and read their output. If the terminal itself is still new territory, the Linux and Bash Scripting tracks in this same DevOps Learning library teach those fundamentals. We install Git itself in Part C, so you do not need it installed yet.
</aside>
<aside> 🖼️
This page contains Mermaid diagram blocks. Notion shows them as code by default — click the block and switch it to Preview to see the diagram. You only need to do this once per block.
</aside>
<aside> 📖
Official docs: Git Book — About Version Control
</aside>
Imagine you keep a server's config file. You are about to make a risky change, so you make a copy first. Next month you do it again. And again. Soon the directory looks like this: app.conf, app.conf.bak, app.conf.old, app.conf.final, app.conf.final2, app.conf.works_dont_touch.
Now answer three questions. Which copy was live last Tuesday, when things still worked? What exactly changed between .final and .final2? Who made the change, and why? You cannot. The information was never recorded. Copies capture content but throw away history: the order of changes, the author, the reason.
A version control system (VCS) exists to record exactly those three things, automatically, for every change: what changed, who changed it, and why (a message the author writes). Once recorded, you can compare any two points in time, restore any earlier state, and read the story of a file backwards.
<aside> 🏠
Real-world analogy — the shop's CCTV vs a photo album
Copy-files-by-hand is a photo album: a few snapshots someone remembered to take, undated, unlabeled, with gaps exactly where the interesting events happened. A version control system is CCTV: it records continuously, every frame is timestamped, and you can wind back to any moment and see who did what.
Where the analogy stops working. CCTV records on its own. A VCS only records when you ask it to save a snapshot — and that is deliberate. You choose the moments worth recording and attach a reason to each one. Uncommitted work is invisible to it, like events outside the camera's view.
</aside>
🧪 Exercise 1.1 — feel the problem
mkdir -p ~/git-course/webapp && cd ~/git-course/webapp
# Recreate the classic mess by hand:
touch app.conf app.conf.bak app.conf.old app.conf.2024-11-03
touch app.conf.works_dont_touch app.conf.final app.conf.final2
ls -1 # -1 = one name per line
<aside> 🏭
Now imagine this at 500 hosts. One person's messy folder is an annoyance. Five hundred servers, each with its own drift of hand-edited configs and .bak files, is an outage generator: no two hosts are provably identical, and no one can say what changed before things broke. This is why fleet tooling (Ansible, Terraform, Kubernetes manifests) keeps its source of truth in a VCS and pushes outward — the repository becomes the one place where change is recorded.
</aside>
<aside> 📖
Official docs: Git Book — About Version Control
</aside>
A version control system is a database of snapshots. You work on your files normally; at moments you choose, you tell the VCS "record the current state." The VCS stores that state, plus who recorded it, when, and a message saying why. Each recorded state is called a commit (we will make our first one in Module 2).
From that simple idea, everything else follows mechanically. Because every snapshot is kept: you can restore any of them. Because snapshots are ordered: you can read history. Because each records its author: you get accountability. Because two people's snapshots can be compared: you get collaboration — merging their work is an operation on recorded states, not on guesswork.
Hold on to this definition: a VCS is a snapshot database plus tools to compare, restore, and combine snapshots. Every Git command in this track is one of those four verbs — record, compare, restore, combine — wearing different clothes.