2️⃣Module 2 — Your First Repository (git init, add, commit, status, diff)

Initialized empty Git repository in /home/aisha/git-course/kitchen/.git/
.git

What to read out of it: the confirmation line names the exact path of the new .git directory — read it every time you init; if the path surprises you, you just initialized the wrong directory. ls -A shows the whole visible result: one hidden entry. No project files were created or changed. Plain ls would show nothing at all — worth trying once to convince yourself the repository is genuinely invisible to normal work. (No hint: lines about branch names here — you configured init.defaultBranch in Module 1; anyone who skipped that sees the hint from Module 1's Exercise 1.8.)

fatal: not a git repository (or any of the parent directories): .git
exit code: 128

What to read out of it: this is one of the most common Git errors in real life, and it is almost always a location problem, not a Git problem. The parenthetical is the informative part: Git looked for .git in /tmp, then in /, walking up the directory tree — that walk is how Git commands work from any subdirectory of a repository. So this error means: neither this directory nor anything above it is a repository. The reflex fix is pwd and cd, not reinstalling anything. Exit code 128 — Git's "fatal error" convention from Module 1.

On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)
On branch main
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	recipe.txt
nothing added to commit but untracked files present (use "git add" to track)

What to read out of it: git status output is built from three parts — a header (On branch main / No commits yet), zero or more sections listing files by state, and a summary line. After creating the file, a new section appears: Untracked files, holding recipe.txt. Notice Git coaches you in parentheses on every section — use "git add" to track — status output is a cheat sheet that tells you the next command. The file's content is irrelevant here: Git has not read it, hashed it, or stored it. It has only noticed a name it does not recognize.

A repository is a project directory that Git tracks: the working files you edit, plus a hidden .git subdirectory holding the complete snapshot database — every commit ever recorded, all branches and settings for that project. The .git directory is the repository in the strict sense; the visible files are just one checked-out state of it. Repositories are self-contained: copying the directory copies the entire history; deleting .git deletes exactly the history and nothing else.

The details that separate candidates: an average answer says "a folder where Git stores your code." A strong answer separates the working files from the .git database and can say what lives where; knows creation is local and instant (git init writes one directory — no server involved); and mentions the special case worth knowing exists: a bare repository (.git contents with no working files), which is what servers host — a pointer to Module 8's material that interviewers often probe right after this question.

For a new project: git init inside an existing directory (or git init <name> to create-and-initialize in one step). That writes the .git directory and nothing else — the first snapshot still has to be made by staging files (git add) and committing them (git commit). A sensible first sequence is: git init, create or copy in the initial files, git add ., git commit -m "Initial commit". For a project that already exists elsewhere, you copy it instead of initializing fresh — git clone <url> — which brings the full history with it (Module 8 covers cloning and everything remote).

The details that separate candidates: an average answer stops at "git init". A strong answer distinguishes the two creation paths (init for new, clone for existing) and states clearly that init alone records nothing — a repository with zero commits protects zero work. Production signal: mentioning that on a server you would create a bare repository (git init --bare) since nobody edits files there, and that in practice most "creating a repo" today happens on a hosting platform first, then gets cloned — the local init path is for projects born on your machine.

On branch main
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   recipe.txt
[main (root-commit) 9c2adb2] Add basic bread recipe
 1 file changed, 1 insertion(+)
 create mode 100644 recipe.txt
On branch main
nothing to commit, working tree clean

What to read out of it: after add, the status section changed from Untracked files to Changes to be committed — that section is the staging area, listed file by file; new file: marks content entering history for the first time. The commit line decodes as: branch (main), root-commit (first snapshot in this repository), 9c2adb2 (the snapshot's short ID — yours differs; Module 3 explains why), your message, then a tally: 1 file, 1 line inserted. create mode 100644 is the file's recorded permission bits — normal non-executable file. The final status is the cleanest sentence in Git: nothing to commit, working tree clean — all three trees now hold identical content.

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   recipe.txt
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   recipe.txt

What to read out of it: recipe.txt appears twice, and both lines are true. Changes to be committed holds the yeast version (photographed at add time); Changes not staged for commit reports that the working tree has since moved on (the sugar edit). Committing right now records yeast, no sugar. To include sugar, run git add recipe.txt again — the newer photo replaces the older one in the draft. The parenthetical hints also introduce git restore, the undo tool Module 7 teaches; you do not need it yet, but notice status already told you it exists.

diff --git a/recipe.txt b/recipe.txt
index 8c3fb3f..4b22a33 100644
--- a/recipe.txt
+++ b/recipe.txt
@@ -1 +1 @@
-flour, water, salt, yeast
+flour, water, salt, yeast, sugar
diff --git a/recipe.txt b/recipe.txt
index 0fd697a..8c3fb3f 100644
--- a/recipe.txt
+++ b/recipe.txt
@@ -1 +1 @@
-flour, water, salt
+flour, water, salt, yeast

What to read out of it: each diff has a header and a hunk. In the header, a/ is the older side, b/ the newer; the index 8c3fb3f..4b22a33 line names the content IDs being compared (Module 3 makes these meaningful — note the first diff's left ID 8c3fb3f equals the second diff's right ID: the staged version is literally the same object in both comparisons). The hunk header @@ -1 +1 @@ means "one line starting at line 1 on both sides"; - lines are the old content, + lines the new. First diff: unstaged sugar edit. Second: staged yeast edit relative to the last commit. Two different questions, two different answers — this is the three-trees model paying rent. Finish the exercise: git add recipe.txt && git commit -m "Add yeast and sugar" — then both diffs print nothing, which is itself information: no differences.

The index — synonym: staging area — is the draft of the next commit. It sits between the working tree (your editable files) and the repository (permanent snapshots): git add copies a file's current content into the index; git commit records exactly what the index holds, and nothing else. It exists to decouple editing from recording: you can change ten things and commit them as three clean, separately-explained commits by staging subsets (git add -p stages individual hunks within a file). Plain git diff shows working-tree-vs-index; git diff --staged shows index-vs-last-commit.

The details that separate candidates: an average answer says "where changes go before commit." A strong answer states the copy-at-a-moment semantics — the index holds content photographed at add time, so a file edited after staging is legitimately listed as both staged and modified, and committing takes the staged version. Naming the mechanics adds depth: the index is a real binary file, .git/index, holding the draft's file list with content references — not a folder of copies. And the punchline interviewers reward: commit never looks at your working tree; it serializes the index. Every "Git committed the wrong version" mystery dissolves under that sentence.

git diff computes line-by-line differences between any two of Git's trees or snapshots. The three forms to know cold: git diff — working tree vs index: edits not yet staged; git diff --staged (a synonym of the older --cached) — index vs last commit: exactly what the next commit will record; git diff <A> <B> — any two commits (Module 4 covers naming commits). Output is unified diff format: ---/+++ name the two sides, @@ hunk headers give line positions, -/+ prefix removed/added lines.

The details that separate candidates: an average answer says "shows changes you made." A strong answer maps each form onto the three-trees model rather than memorizing flags, and knows the review habit (git diff --staged before every commit). Practical extras that signal fluency: --stat for a per-file change summary instead of full text, --word-diff for prose, and the fact that diffs are computed on demand from snapshots — Git stores full states, not diffs (Module 1), so diff output is derived, which is why any two arbitrary commits can be compared instantly.

[main b34a325] Add oil to recipe
 1 file changed, 1 insertion(+), 1 deletion(-)
On branch main
nothing to commit, working tree clean

What to read out of it: no git add was typed, yet the change was committed — -a staged it in passing. The tally reads 1 insertion(+), 1 deletion(-) even though you "changed one word": Git diffs whole lines, so editing a line counts as removing the old line and adding the new one. Now try the same trick with a brand-new file (touch pancakes.txt && git commit -a -m "x") — on a clean tree it fails (exit code 1) saying nothing added to commit but untracked files present, and if a tracked change is also present it commits without the new file — either way proving -a ignores untracked files. Clean up the experiment with rm pancakes.txt if you made it.

rm 'scratch.txt'
D  scratch.txt
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    recipe.txt -> bread.txt

What to read out of it: git rm echoes what it removed, and short-status shows D — a staged deletion. After git mv, status says renamed: recipe.txt -> bread.txt — one staged operation, not a delete-plus-add pair. Under the hood it is a delete plus an add (Git stores snapshots, not rename instructions — Module 1); Git detects renames by noticing identical content under a new name. The renamed: line is Git being helpful about what it inferred, which is also why renaming and heavily editing a file in the same commit can show up as delete + new file instead: change enough content and the inference fails. Rename in one commit, rewrite in the next, and history stays readable.

[main c42592d] Add servng info
 1 file changed, 1 insertion(+)
 create mode 100644 serving.txt
[main eba71cd] Add serving info
 Date: Mon Sep 7 16:17:32 2026 +0000
 1 file changed, 1 insertion(+)
 create mode 100644 serving.txt

What to read out of it: compare the two IDs — c42592d became eba71cd. The amended commit is a new snapshot; the typo'd one is no longer part of your branch's history. The amended output also shows a Date: line: Git kept the original author date rather than pretending the work happened at amend time — your amendment is honest about when the change was made. Same file, same content, different commit identity: hold onto that observation, because Module 3 explains precisely why any change to a commit — even one letter of its message — must produce a new ID.

git commit --amend. It rebuilds the most recent commit from the current index: to fix only the message, run it with nothing newly staged and pass -m "better message" (or let the editor open); to add a forgotten change, git add the file first, then git commit --amend --no-edit — the commit now includes it under the original message. Amend replaces the commit: the old ID disappears from the branch and a new one takes its place, preserving the original author date.

The details that separate candidates: an average answer names the command. A strong answer says what amend really is — a replacement, not an edit — and draws the operational line: safe while the commit exists only on your machine; risky once pushed, because teammates may already have the old commit, and the two histories then disagree (the full rules live in history rewriting, Module 10). Bonus fluency: amend only reaches the last commit; anything deeper needs interactive rebase — and knowing that boundary is itself a signal.

It depends on one question: has the broken commit been shared? If it is still local-only, amend (or otherwise rewrite) — the fix vanishes into a clean history, and nobody ever sees the breakage; a repository whose every commit builds and makes sense is a gift to future readers and to tools like bisect (Module 13). If it has been pushed where others may have based work on it, add a new commit that fixes the problem — rewriting shared history forces everyone downstream to repair their copies, which costs the team more than an ugly commit does.

The details that separate candidates: an average answer picks one option universally ("always amend" or "always new commit"). A strong answer states the shared/unshared boundary as the deciding rule and explains why it decides — rewriting replaces commit IDs, and replaced IDs break everyone who holds the old ones. Naming git revert (Module 7) as the tool that formalizes "fix by new commit" — an inverse commit that undoes a bad one without touching history — turns a good answer into a complete one.

?? method.txt
A  method.txt
AM method.txt

What to read out of it: the file walks through Git's states one command at a time — untracked (??), staged-new (A␣), then AM: column 1 still says "new file staged", column 2 says "edited since". Note the final git status -s prints nothing at all — in short format, a clean tree is silence, which is why scripts and shell prompts use it (--porcelain, its stable cousin, is built for exactly that — you will meet it in CI contexts). If your third line said A instead of AM, you edited before staging rather than after — order is the whole lesson here; run it again.

[main 3f19e02] Add baking temperature and time
 1 file changed, 1 insertion(+)
 create mode 100644 baking.txt

What to read out of it: the confirmation shows only the subject line — exactly how most tools will display this commit forever, which is why the subject must stand alone. The body is stored too (Module 4's git log shows full messages). The editor buffer came pre-filled with #-commented status lines; anything starting # is stripped from the final message — they are guidance, not content. If instead you saw Aborting commit due to empty commit message., you closed the editor without saving: no harm done, the staging area still holds baking.txt — just run git commit again.

git status reports, for the current repository, how the three trees currently disagree: which files are untracked, which have working-tree edits not yet staged, and which staged changes await commit — each in its own section, with the exact next command suggested in parentheses. It reads state only; it changes nothing, so it is always safe to run. The short form -s compresses each file to a two-column code (index state, working-tree state), and --porcelain guarantees a stable format for scripts.

The details that separate candidates: an average answer says "shows changed files." A strong answer frames the output as three pairwise comparisons (working tree vs index, index vs last commit, plus the untracked bin) rather than one list — which explains how one file can appear in two sections at once — and demonstrates they read the codes: MM means staged then re-edited; committing now takes the staged version. Operational touch: naming --porcelain as the scripting interface, because parsing human-format status in automation is a classic junior mistake.

A commit is one recorded snapshot of the entire project, created from the staging area's contents, plus metadata: author and email (from config), timestamp, a message explaining why, and a reference to the commit that came before it. Each commit has a unique hash ID by which it can be inspected, compared, restored, or reverted later. Commits are immutable — "changing" one (as --amend does) actually creates a replacement with a new ID.

The details that separate candidates: an average answer says "a saved change." A strong answer corrects the two embedded misconceptions: a commit snapshots the whole project state, not a patch (Module 1's snapshot model), and it is built from the index, not the working tree — uncommitted-because-unstaged edits are excluded by design. Adding that each commit points to its parent, forming a chain that gives history its integrity — modify any old commit and every later ID changes — anticipates the internals (Module 3) and reads as real understanding rather than command recall.

What is really happening: Neither the current directory nor anything above it contains .git — wrong location, or the repo was never initialized.

Diagnose: pwd · ls -A

The fix: cd to the project, or git init if it truly was never a repo.

What is really happening: The file was edited after git add — the commit recorded the staged photo, not the disk version.

Diagnose: git status -s (look for MM/AM) · git diff

The fix: git add the file again and git commit --amend --no-edit (if unshared), or make a follow-up commit.

What is really happening: -a stages modifications to tracked files only; untracked files are never auto-added.

Diagnose: git status (the file sits in Untracked files)

The fix: git add <file> explicitly, then commit.

What is really happening: Nothing is staged and no tracked file changed — often you already committed, or edited a file outside the repo.

Diagnose: git status · git log --oneline -3 (Module 4)

The fix: Check the last commit already contains the work; otherwise find where your edits actually went (pwd).

What is really happening: The disk deletion is not staged — the index still holds the file.

Diagnose: git status -s (shows ␣D)

The fix: git rm <file> (or git add <file> — staging a deletion is also an add), then commit.

What is really happening: The file entered the index at some point; Git keeps tracking until told otherwise.

Diagnose: git status · check what tracks it

The fix: git rm --cached <file> and commit; note past commits still contain it — true scrubbing is Module 10/15 territory, so rotate real secrets.

What is really happening: The editor was closed without saving a message — Git treats that as "cancel".

Diagnose: git status (staged changes are intact)

The fix: Run git commit again and save this time, or use -m.

git init creates exactly one thing: a hidden .git subdirectory containing an empty snapshot database and Git's bookkeeping files — no registration, no daemon, no server. That directory is the entire difference between a folder and a repository. Delete .git and the directory is just a folder again: your project files are untouched, but all recorded history is gone.

Git looked for a .git directory in the current directory, then walked up the directory tree toward / and found nothing — that upward walk is how Git commands work from any subdirectory of a repository. The error therefore means neither this directory nor anything above it is a repository. It is almost always a location problem, not a Git problem: the reflex fix is pwd and cd, not reinstalling anything. Exit code 128 is Git's fatal-error convention.

Working tree (the real files you edit) → staging area, also called the index (the draft of the next snapshot) → repository (the permanent snapshot database inside .git). git add copies a file's current content from the working tree into the staging area; git commit seals whatever the staging area holds into a permanent snapshot.

It exists to make commits deliberate — to decouple editing from recording. The scenario: after two hours of debugging, your working tree holds the fix, plus stray experiments, plus a config tweak. Committing everything would record a bucket of "stuff I had at 6pm"; the staging area lets you pick exactly what belongs in the snapshot — the fix alone — so the commit is a curated unit of change with an honest message.

git status -s shows MM (or AM if the file was newly added): column 1 says one version is staged, column 2 says the working tree has been edited since. Committing right now records the staged version — the content photographed at git add time — not what is on disk. To include the newer edit you must run git add again so the newer photo replaces the older one in the draft.

Plain git diff compares the working tree against the staging area — "what have I edited but not yet staged?". git diff --staged compares the staging area against the last commit — "what exactly will the next commit record?". Reading git diff --staged before every commit is the habit that prevents committing debris — the parcel opened for one final look before sealing.

-a auto-stages modifications to every tracked file, then commits. It never stages untracked files — a new file still needs an explicit git add, because Git will not guess that a new file belongs in history. It also stages everything modified, throwing away the selectivity the staging area exists for — so use it only for small, everything-belongs-together changes.

git rm <f> deletes the file from disk and stages the deletion in one move. git rm --cached <f> removes the file from tracking while leaving it on disk — that is the one that solves "stop tracking my config file but leave it on disk". Remember that past commits still contain the file; true scrubbing is Module 10/15 territory.

Amend does not edit — it replaces: it takes the current staging area plus a message and substitutes a corrected commit for the last one. The result is a different snapshot with a different ID (Exercise 2.9's c42592d became eba71cd), and the typo'd commit is no longer part of your branch's history. Git keeps the original author date, so the amendment is honest about when the work happened. Because IDs change, amend freely only until your commits leave your machine.

Subject: around 50 characters, imperative mood ("Add retry to health check" — read it as "if applied, this commit will ___"), no trailing period. Body, after a blank line and only when needed: the why — what was wrong and why this approach; the diff already shows the what. The test: could a teammate decide whether this commit is relevant to their bug without opening the diff? "Update config" fails that test; "Raise DB pool size to stop timeout storms" passes.