<aside> 🔀
Module 2 — Your First Repository (git init, add, commit, status, diff). This is where Git becomes something you do: you will turn a directory into a repository and record real snapshots. The staging area you meet here is Git's most misunderstood idea — and the habit of reading git status correctly will serve you in every module after this one.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 1: Git installed (git --version works), your identity set (git config user.name prints your name), and init.defaultBranch set to main — the outputs below assume it. Tools: just Git and a terminal. If the shell itself is still new, the Linux and Bash Scripting tracks in this same DevOps Learning library cover it.
</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-init manual · Git Book §2.1 — Getting a Git Repository
</aside>
A repository is a directory that Git is watching: your project files, plus the snapshot database from Module 1 living alongside them. git init is what starts the watching. It does exactly one thing: creates a hidden subdirectory called .git in the current directory, containing an empty snapshot database and Git's bookkeeping files. That is the entire difference between "a folder" and "a repository" — no registration, no daemon, no server. Delete .git and the directory is just a folder again; your files are untouched, but all recorded history is gone.
Everything Git will ever record about this project lives inside that one .git directory. Module 3 opens it up and reads it; for now, treat it as Git's private filing room and never edit it by hand.
<aside> 📓
Real-world analogy — hiring a notary for one filing cabinet
git init is hiring a notary who moves into a small back office (.git) of one specific filing cabinet (your directory). The notary only certifies documents from this cabinet, keeps every certified copy in the back office, and has no idea other cabinets exist. Firing the notary (deleting .git) empties the back office — the cabinet's current papers stay exactly where they are.
Where the analogy stops working. A notary certifies what you show them and remembers being shown it. Git's notary records nothing automatically — a repository with no commits is an empty archive even after months of editing files in it. And unlike a notary's ledger, the back office is on your disk, under your control: no external authority, no independent witness. That is why "it's in Git" only means something after you commit — and, later, share it.
</aside>
🧪 Exercise 2.1 — create a repository and see what appeared
cd ~/git-course
git init kitchen # "git init <name>" creates the directory AND initializes it
cd kitchen
ls -A # -A = show hidden entries too (names starting with .)
🧪 Exercise 2.2 — a deliberate failure: ask for status outside any repository
cd /tmp # a directory that is not a repository
git status
echo "exit code: $?"
<aside> 📖
Official docs: git-status manual · Git Book §2.2 — Recording Changes
</aside>
Initializing the repository did not put your files under version control. Git sorts every file in the directory into two bins. Tracked files are ones Git has been explicitly told about — they are in the snapshot database (or staged to enter it), and Git watches them for changes. Untracked files are everything else: present on disk, visible to you, and completely ignored by Git's history machinery until you say otherwise. Git never starts tracking a file on its own — you opt each file in. That is a feature: build outputs, editor droppings, and secrets stay out of history unless someone deliberately adds them.
git status is the command that shows the sorting. You will run it constantly — before and after almost everything — because it answers the only three questions that matter mid-work: what is untracked, what changed, and what will go into the next snapshot.