Lesson 06 — Professional Git

Exercises 1-5 run in a lab repo (~/dev/git-lab) so you can break things fearlessly. Exercise 6 goes on your real TicketFlow. Do not look at solutions.md before submitting.

Setup:

mkdir -p ~/dev/git-lab && cd ~/dev/git-lab
git init && echo "# Git Lab" > README.md
git add . && git commit -m "chore: lab starts"

Exercise 1 — Commits with intention (add -p)

1. Edit a file app.py adding TWO independent changes: a fix (typo in an error message) and a feature (a new function). All in the same file.
2. With git add -p, split into two commits: fix: correct error message and feat: add function X. (use s to split hunks if needed; if the changes share a hunk, separate them by editing with e).
3. git log --oneline: did you end up with two clean commits? What would have happened with git add. and a single "update" commit?

Exercise 2 — Interactive rebase: the history you will tell yourself

1. Make three careless commits: echo 1 > a.txt; git add.; git commit -m "wip", then echo 2 >> a.txt;... -m "fix" and echo 3 >> a.txt;... -m "wip2".
2. git rebase -i HEAD~3 and with squash/reword turn them into a single feat: add counters to a.txt.
3. git log --oneline: compare before and after. Which commits disappear (old hashes)? Why is it safe here and dangerous on a shared branch?

Exercise 3 — Simulated and solved conflict

1. Create branch feature-a: change line 1 of README.md to "Version A" and commit. Back on main, change the same line to "Version B" and commit.
2. git merge feature-a: what does Git say exactly? Open the file and examine the <<<<<<< ======= >>>>>>> markers.
3. Resolve (pick A, B or a third wording), git add and finish the merge. Delete the branch. git log --graph --oneline --all: describe the resulting graph.
4. Repeat the scenario with rebase instead of merge (new branch, same conflict): how does the final graph differ?

Exercise 4 — Rescue with reflog

1. In the lab, make any commit and note its hash: git log --oneline -1.
2. "Shoot yourself in the foot": git reset --hard HEAD~1.
3. Find the "lost" commit with git reflog and recover it with git reset --hard HEAD@{n} (or create a branch pointing at it). Verify with git log.
4. Write in one line when you would use reflog vs git revert (hint: did the commit already reach the shared main?).

Exercise 5 — Bisect with an automatic suite

1. Create a test.sh script that fails if the file bug.txt exists:

#!/usr/bin/env bash
if [[ -f bug.txt ]]; then echo "FAIL"; exit 1; fi
echo "OK"; exit 0

1. Make 5 commits; on the 4th create bug.txt (and on the 5th add a different file).
2. Run: git bisect start HEAD HEAD~4 (bad = HEAD, good = 4 back) and then git bisect run./test.sh. Which commit does it point at? Does it match the one that created the bug?
3. git bisect reset. How many tests did Git run to locate it? How many would you have done by hand?

Exercise 6 — GitHub Flow on your TicketFlow (solo simulation)

1. On your real repo: create feat/detailed-health and add a /api/health/detail/ endpoint returning the process version and uptime (2 fields, little code).
2. Commit with the full conventional message (feat + body with the why) and push the branch to GitHub (git push -u origin feat/detailed-health).
3. Open the PR: conventional title, description with context and a checklist. Review yourself with two honest observations.
4. Merge with squash. git log --oneline: how did history end up? Was the branch deleted (the button's option)?

Submit

Paste the outputs (log --graph, reflog, bisect result) and the link/content of your PR. Lesson 06 closes and with it the whole Module 1: we move to Lesson 07 — Advanced SQL (module 2, the craft's most decisive skill).