Exercises + milestone requirements owned by this stage
Evidence and gate
0 · 0/10
Artifacts · checked requirements
Why it matters
Purpose of this stage
Stage 1 already introduced `git init`, `status`, `add`, `commit`, `log`, `remote`, `push` and `.gitignore` so work could be saved. This stage owns the model behind them and everything beyond saving: branching, merging, conflicts, recovery, and repository hygiene.
Subjects
2 subjects · 24 canonical topics
Each subject states what you should be able to do, an order to work through it in, what to watch for, and the questions a reviewer should be able to ask you at the end. None of it is tracked or scored.
How to work through this subject
An order that works, not a checklist. Nothing here is tracked — the steps sequence this subject’s own topics and add none.
Change a file and follow it through modified, staged and committed, running `git status` and `git diff` at each step.
Read your own history with `git log`, then read one commit's diff and check it does exactly one thing.
Create a branch, commit twice on it, switch back to main and confirm the work is absent from the working tree.
Merge the branch and read the resulting history, noting whether it fast-forwarded and why.
Cause a conflict on purpose by editing the same line on two branches, then resolve it and remove every marker.
Practise the three recoveries — discard an unstaged change, unstage a staged file, undo an unpushed commit — and write down which command did which.
Finish by pushing and pulling against the remote until synchronising is uneventful.
What to watch for
Three states — modified, staged, committed — explain nearly every confusing Git moment.
Create a conflict on purpose. Resolving one you caused is much cheaper than resolving your first one under pressure.
A branch is a moving pointer at a commit, not a copy of your files. Once that lands, checkout and merge stop being mysterious.
`git diff` with nothing staged and `git diff` of the staged content answer different questions. Know which one you are asking.
Rewriting history you have pushed affects other people; rewriting local history affects nobody. That distinction decides which recovery command is safe.
Never solve a Git problem by deleting and recloning. The point of this stage is that you do not have to.
Curriculum topics
repository
The project folder Git tracks, including its full history.
working tree
The actual files on disk as they exist right now, edits included.
staging
The in-between area where you assemble exactly the changes that will go into the next commit.
commit
A permanent snapshot of the staged changes, with a message explaining why.
`.gitignore`
A file listing paths Git should not track — build output, virtual environments, and anything secret.
history
The ordered record of commits, showing how the project reached its current state.
diff
The line-by-line difference between two versions of a file.
branch
A movable pointer to a commit, letting you develop a change without disturbing the main line.
merge
Combining the work of two branches into one.
remote
A copy of the repository hosted elsewhere, such as on GitHub.
push/pull
Sending your commits to a remote, and fetching others' commits from it.
conflict resolution
Deciding the final content when two branches changed the same lines and Git cannot choose for you.
Resources for this subject
PRIMARYPro Git git-scm.com The book that explains what Git is doing, not only which command to type. Chapters 1 to 3 cover this stage; read the branching chapter before the branching practice, not after it.Open
Need another explanation?3 more references
REFERENCELearn Git Branching learngitbranching.js.org An interactive visualiser for branches and merges. The fastest way to build the mental model Pro Git describes in prose.Open
REFERENCEGitHub — Get started GitHub Covers the remote half of Git, which Pro Git treats more abstractly. Needed from Week 1 since the roadmap requires a single learning repository.Open
OPTIONALConventional Commits conventionalcommits.org A commit-message convention that makes the changelog required by the Stage 2 project mechanical rather than manual.Open
A reviewer should be able to answer these
Answer from memory, out loud, before moving on. These are not tracked and do not affect the gate — they tell you whether you actually understand this subject.
What are the modified, staged and committed states, and what moves a file between them?
What does a branch actually point to?
What causes a merge conflict, and what are you deciding when you resolve one?
How do you undo a commit you have not pushed, and how does that differ from one you have?
What belongs in `.gitignore`, and why is committing a secret hard to undo?
What is the working tree, and how does it differ from the repository?
What does `git diff` show before staging versus after, and why are they different?
What does pushing do that committing does not, and what can make a push refuse?
Exercises
Demonstrated practice · 35% base weight
create repository
warmup ~20 min
Initialise a repository for the learning project with a sensible ignore file.
What to implement
Initialise the repository and make an initial commit.
Add a `.gitignore` covering virtual environments, caches and local config.
Confirm ignored files do not appear in status.
Write the `.gitignore` before the first commit, not after.
Inspect the log after the initial commit and confirm it contains only what you intended.
Done when
`git status` is clean with the virtual environment present on disk.
No generated or secret file is tracked.
You can name every file the first commit tracked.
Adding a new cache or environment directory does not dirty the status.
One hint, available after you have made a real attempt.
make atomic commits
core ~30 min
Split a mixed set of changes into commits that each do one thing.
What to implement
Make changes touching at least two concerns.
Stage and commit them separately.
Write messages saying why, not what.
Verify each commit could be reverted independently.
Review the staged diff before every commit rather than after.
Done when
The log reads as a sequence of decisions rather than a diary.
No commit mixes a fix with a refactor.
Each message would still make sense to you in six months.
You can describe each commit's purpose in one sentence without opening the diff.
One hint, available after you have made a real attempt.
branch a feature
core ~25 min
Create a branch, do work on it, and confirm main is untouched.
What to implement
Create and switch to a feature branch.
Commit at least two changes on it.
Switch back to main and confirm the work is absent.
Switch back and confirm it returns.
Check the log on both branches and note where their histories diverge.
Done when
You can state what changed on disk when you switched branches.
Main's history does not contain the feature commits yet.
You can say what a branch points at, without saying 'a copy'.
The working tree changed exactly as you predicted when you switched.
One hint, available after you have made a real attempt.
merge it
core ~25 min
Merge the feature branch into main and read the resulting history.
What to implement
Merge the branch into main.
Inspect the log and identify the merge.
Note whether it fast-forwarded and explain why.
Delete the merged branch.
Move main forward before merging once, so you can compare both outcomes.
Done when
You can explain why the merge did or did not create a merge commit.
The history is readable to someone who was not there.
You have produced both a fast-forward and a merge commit, deliberately.
You can read the merge in the log without needing a graphical tool.
One hint, available after you have made a real attempt.
intentionally create a conflict
core ~25 min
Deliberately produce a merge conflict so your first one is not during real work.
What to implement
Edit the same line on two branches.
Attempt the merge and observe the failure.
Read the conflict markers and identify each side.
Check the status while the merge is in progress and read what Git says the state is.
Abort the merge once, and confirm the repository returns to where it started.
Done when
You can point at the marker showing your change versus theirs.
You understand why Git could not decide for you.
You can abort a conflicted merge without fear.
You can explain what information Git had, and what it lacked, when it stopped.
One hint, available after you have made a real attempt.
resolve it
core ~30 min
Resolve the conflict you created and complete the merge.
What to implement
Choose the correct final content, not just one side.
Remove all conflict markers.
Stage the resolution and complete the merge.
Confirm the result builds and tests pass.
Inspect the merged file's diff before committing the resolution.
Done when
No conflict marker survives anywhere in the repository.
The merged result is what you actually wanted, not whichever side was easier.
The commit contains only the resolution, not unrelated edits made while you were in there.
You can explain why the result is correct rather than merely conflict-free.
One hint, available after you have made a real attempt.
revert/fix a mistake
stretch ~45 min
Practise recovering from three common mistakes without deleting the repository.
What to implement
Undo an unstaged change to a file.
Unstage a file you staged by accident.
Undo a commit you have not pushed.
Write down which command you used for each and why.
Recover a file you deleted but had previously committed.
Done when
You have recovered from all three without cloning afresh.
You can explain the difference between undoing a commit and reverting one.
None of the four recoveries required deleting or recloning the repository.
You can say which of your commands rewrote history and which added to it.
One hint, available after you have made a real attempt.
tag a release
warmup ~20 min
Tag a commit as a release and explain what a tag is for.
What to implement
Create an annotated tag on a meaningful commit.
List tags and inspect the annotation.
Explain how a tag differs from a branch.
Push the tag and confirm it appears on the remote.
Check out the tag and observe what happens to the working tree.
Done when
The tag carries a message describing what the release contains.
You can say why a tag is not just a branch that stopped moving.
The tag is visible on the remote alongside the branch.
You can explain why a tag does not move when new commits arrive.
One hint, available after you have made a real attempt.
Resource status is a convenience marker only. It cannot change competencies, gates, or stage completion — in any tier below.
Start here
PRIMARY
Pro Git
git-scm.com
The book that explains what Git is doing, not only which command to type. Chapters 1 to 3 cover this stage; read the branching chapter before the branching practice, not after it.
Need another explanation?5 supplementary resources · not part of the canonical library
Use these for a demonstrated gap, not as a parallel course. They are authored additions and can never be the primary resource for a subject.
REFERENCEPEP 8 — Style Guide for Python Code Python Software FoundationThe conventions every Python codebase assumes. Relevant the moment your code is read by someone else — which Stage 2 makes real.Open
REFERENCELearn Git Branching learngitbranching.js.orgAn interactive visualiser for branches and merges. The fastest way to build the mental model Pro Git describes in prose.Open
REFERENCEGitHub — Get started GitHubCovers the remote half of Git, which Pro Git treats more abstractly. Needed from Week 1 since the roadmap requires a single learning repository.Open
OPTIONALConventional Commits conventionalcommits.orgA commit-message convention that makes the changelog required by the Stage 2 project mechanical rather than manual.Open
REFERENCEPython Packaging User Guide PyPAThe authority on `pyproject.toml` and dependency declaration, both required by the Stage 2 project.Open
Stage gate
Readiness assessment
Not ready
Stage-specific requirements
Answer each prompt without notes. Expand a question only when you are ready to check your answer.
0/2
Explain modified/staged/committed states
Answer
Modified means the file differs from the last commit but Git has not been told to include it. Staged means you have selected that change for the next commit. Committed means it is recorded in history. `git add` moves modified to staged, `git commit` moves staged to committed, and `git status` tells you where everything currently sits.
Recover from common Git mistakes without deleting the repository
Answer
Discard an unstaged change by restoring the file from the last commit. Unstage an accidentally staged file by moving it back out of the index. Undo a local, unpushed commit by resetting to the previous one, keeping or discarding the changes as you choose. For a commit already pushed, add a revert commit rather than rewriting shared history. None of these require deleting or recloning the repository.
Universal requirements
The eight conditions 01_LEARNING_RULES.md applies to every stage. Expand one to see what it actually asks for.
0/8
Core concepts can be explained from memory.
What this asks for
Every subject in this stage has review questions. The condition is met when you can answer them out loud, without notes and without looking anything up, in your own words rather than a recited definition. An explanation you can only give with the material open is recognition, not recall.
Required exercises are complete.
What this asks for
Complete means each exercise satisfies its stated requirements and its done-when criteria, not that you attempted it. Where an exercise says you should be able to explain or defend something, that explanation is part of completing it. A stage whose source lists no exercises meets this through its owned project milestone instead.
Stage project works.
What this asks for
Works means it runs end to end from a clean checkout, on the inputs it was built for, with the failure cases it claims to handle actually handled. It is not a notebook that produced a result once. Someone else following your README should be able to run it without asking you a question.
Tests or verification exist.
What this asks for
There is something that would fail if the behaviour regressed, and you have watched it fail. That can be automated tests or a written verification procedure with recorded results, depending on what the stage produces. A test that has only ever passed is evidence of nothing.
README explains decisions.
What this asks for
The README says what the project is, how to install, run and test it, and why it is built the way it is: the choices you made, the alternatives you rejected, and what you deliberately left out. A list of commands with no reasoning does not meet this condition.
You can reproduce the core implementation without copying.
What this asks for
Delete the central piece and write it again from an empty file, without your previous version, a tutorial, or generated code in front of you. It does not have to be identical, it has to work and you have to be able to explain every line. This is the condition that separates having finished from being able.
You pass the stage self-assessment at >= 80%.
What this asks for
Record a gate exam and score yourself honestly against the dimensions the roadmap defines: recall, implementation, debugging, testing and design judgment. Elapsed time, hours watched and completed resources count for nothing here. Checking the boxes without a recorded exam does not open the gate.
Claude/ChatGPT reviewer finds no foundational blocker.
What this asks for
Ask an AI reviewer to examine the work against this stage's concepts and report foundational misunderstandings, not style. A foundational blocker is a misconception that later stages would build on, such as leakage, a broken abstraction, or an explanation that is confidently wrong. Nothing in that class may remain open when you pass.
Recorded exam
No exam recorded. Checking every requirement is not sufficient.