Part 11 of 11 · 4 min read
Exercises
Easy
Easy 1: Name the three areas (15 minutes)
Draw (on paper is fine) the working directory, the staging area and the repository. Mark which command moves a change from each to the next (git add, git commit) and which command shows the difference between each pair.
Done when: your drawing has three boxes, two arrows and three "diff" commands.
Easy 2: Write three good commit messages (15 minutes)
Here are three bad messages: "fix", "changes", "update stuff". Invent the change each might hide and rewrite each as a one-line message that says what and why.
Done when: each rewrite names a specific behaviour.
Easy 3: Review a diff (20 minutes)
Take the change below and write three review comments, each naming a concrete risk. The change replaces httpx.get(url, headers=headers) with httpx.get(url, headers=headers, timeout=60), adds print("calling", url, headers) and returns r.json() directly.
Done when: you spotted at least the leaked header (it contains the API key), the missing status check, and the very long timeout.
Hint
also ask whether the timeout is needed at all in a function that may be called many times in a row.
Medium
Medium 1: The full loop in a throwaway repo (30 minutes)
Create a new folder, run git init -b main, and commit a file app.py. Create the branch feature/shout, add a function, commit, switch back to main and merge. Run git log --oneline --graph --all and sketch what you see.
Done when: you can explain each line of the log graph.
Medium 2: Create and resolve a conflict on purpose (30 minutes)
On main and on a feature branch, edit the same line of the same file differently. Merge the branch, open the file, resolve the markers, run a test or the script, and commit. Repeat with git rebase main on the feature branch and notice what is different.
Done when: you have resolved the same conflict both ways and can say which history you prefer, and why.
Hint
after a failed merge git status lists the conflicted files, and git diff shows both sides.
Medium 3: Rescue a leaked secret (20 minutes)
In a practice repo, commit a file .env containing API_KEY=not-a-real-key. Then (a) add .env to .gitignore, (b) remove it from tracking with git rm --cached .env, (c) show with git log -p that the value is still in history. Write down the real-world steps you would take, in order.
Done when: your list starts with "rotate the key".
Hint
git log -p -- .env shows every version of that file that was ever committed.
Hard
Hard 1: Your first real pull request (60 minutes)
Put the triage-service from module 1 on GitHub. On a branch, add a --shout option to the command. Open a pull request using the template above and review it yourself as if you were someone else: leave at least two comments, then address them in new commits.
Done when: the PR has a description, at least three commits and two resolved review comments.
Hard 2: Find the bug with bisect (45 minutes)
In a throwaway repo, make ten commits to a small script that prints a number. Break the output in commit 6 without saying so in the message. Write a one-line test script that exits non-zero when the output is wrong, then use git bisect run to find the commit automatically.
Done when: bisect names commit 6 without you checking out any commit by hand.
Hint
git bisect start, git bisect bad, git bisect good <commit>, then git bisect run ./check.sh. The script's exit code decides good or bad.
Hard 3: Clean a messy branch before review (45 minutes)
Make a branch with six commits including "wip", "typo" and "fix typo again". Use an interactive rebase (git rebase -i main) to squash them into two commits with clear messages, then confirm with git diff main that the final content is unchanged. Note when you would not rewrite history.
Done when: the content is identical before and after, you have two clean commits, and you can state the rule about shared branches.
Hint
the interactive rebase editor lists commits oldest first; change pick to squash (or s) on the ones to fold into the one above. Do this only on branches nobody else has pulled.