Git From Zero

An agent is about to edit your files. Dozens of them, fast, sometimes wrong. The only reason that prospect is exciting instead of terrifying is a program from 2005 that remembers every version of everything and can put any of it back. People who fear git avoid the undo features because they have never used them under calm conditions. So today you will break a repository on purpose, five ways, and fix it five ways, and after that the fear has nothing left to grip.

The map

Git is a save-point system. A commit is a snapshot of your entire project at a moment you chose, with a message saying why. The chain of commits is your project's history, and git can show you any snapshot, the difference between any two, or bring any of them back.

Three zones matter. Your working directory is the files as they are right now. The staging area is the loading dock: git add file puts a file's current state there, meaning "include this in the next snapshot." git commit seals everything staged into a permanent snapshot. This two-step design is a feature, not bureaucracy: you can edit five files and commit two of them as one coherent change.

The commands you will use daily:

• git init starts tracking a directory
• git status shows what changed and what is staged (run it constantly, it is free)
• git add file stages, git commit -m "why" snapshots
• git log --oneline lists history, newest first
• git diff shows unstaged changes line by line
• git branch and git switch manage parallel lines of work
• git merge other-branch combines a branch into the current one

A branch is a movable label pointing at a commit. Creating one costs nothing. You work on main normally; when you want to try something without risking it, git switch -c experiment starts a branch, you commit freely there, and main stays untouched until you merge. When both branches changed the same lines, git stops and asks you to decide: that is a merge conflict, and it looks scarier than it is. Git writes both versions into the file between <<<<<<< and >>>>>>> markers; you edit the file to the final content you want, delete the markers, add, and commit. That is the entire procedure.

Remotes are copies of the repository elsewhere, usually GitHub. git push sends your commits up, git pull brings others' commits down. Part 0 covers the GitHub workflow properly; today is about the local safety net. One more file matters now: .gitignore, a list of paths git should never track (dependency folders, secrets, build output). Add node_modules/ and .env to it in every project, day one, and future-you avoids the classic mistakes of committing 200MB of dependencies or an API key.

Tutor first

The lab: break it, then fix it

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

cd && mkdir git-lab && cd git-lab
git init -b main
echo "# Recipe Box" > README.md
git add README.md
git commit -m "first commit: readme"
printf 'Chili\n- beans\n- tomatoes\n' > chili.txt
git add chili.txt
git commit -m "add chili recipe"
git log --oneline

git switch -c spicy
printf 'Chili\n- beans\n- tomatoes\n- three habaneros\n' > chili.txt
git add chili.txt && git commit -m "spicy version"
git switch main
printf 'Chili\n- beans\n- tomatoes\n- mild green chiles\n' > chili.txt
git add chili.txt && git commit -m "mild version"
git merge spicy

git add chili.txt
git commit -m "merge: both heats"

echo "GARBAGE" > README.md
git status
git restore README.md
cat README.md

echo "- salt" >> chili.txt
git add chili.txt && git commit -m "oops wrong messgae"
git reset --soft HEAD~1
git status
git commit -m "add salt"

rm chili.txt
git restore chili.txt
ls

echo "- a cup of mayonnaise" >> chili.txt
git add chili.txt && git commit -m "mayo experiment"
git revert --no-edit HEAD
grep mayonnaise chili.txt

git log --oneline
git reset --hard HEAD~2
git log --oneline

git reflog

git reset --hard HEAD@{1}
git log --oneline

Where it breaks

Git's undo tools differ on one axis that matters: whether history is rewritten. restore touches only your working files. revert adds new history. reset rewrites it. On a repo only you touch, rewriting is fine. The moment commits exist on a shared remote, rewriting history you have pushed creates a mess for everyone who pulled it, so the rule is: private history, reset freely; shared history, revert only. You will not share repos until Part 0, but install the rule before the stakes exist.

And the failure mode agents specifically create: an agent makes forty edits, you like thirty of them, and there is no commit anywhere. Now sorting the keepers from the junk is archaeology. The discipline that prevents this costs one command: commit before you let an agent loose, and commit when it finishes something you like. Checkpoints only help if you place them.

Knowledge check

Sources

Git's core commands have been stable for many years, including the newer restore and switch (introduced in 2019, standard everywhere now). No volatile claims to cite. Every command sequence and its expected output in this lesson was executed and verified during authoring (July 2026).