Lab: review and reverse a runbook change

Work in the disposable repository

Use the Git bites' repository, with your own locally configured author identity. Check that it contains only practice files and has a clean working tree. Keep existing work repositories separate from this exercise.

Before the new change, record its starting point with study_review_base=$(git rev-parse HEAD). Keep this terminal open so the variable remains available.

Build and review

1. Create a branch for a short runbook change.
2. Add a paragraph explaining how to identify a failed local service before restarting it.
3. Inspect the working diff, stage that file, inspect the staged diff, and commit.
4. Write a review description covering the problem, change, verification, and limitations.
5. Read the diff as a reviewer. Check target names, command assumptions, recovery, and cleanup.

You can perform this as a local review without publishing a pull request. If you later open a PR in a repository you own, use its normal review policy.

Read the review as another learner

Check the proposed service paragraph for these concrete distinctions: start versus enable; daemon-reload versus an application's reload; the actual service name rather than an unexplained placeholder; and process state versus an HTTP response. Choose one observable check that supports the paragraph. A clean diff can still teach the wrong operation.

For the local review comparison, use the starting commit you recorded before the change. After committing the paragraph, git diff "$study_review_base" HEAD -- runbook.md displays exactly the change for this round. A fresh branch name such as docs/service-check should be unused; if it exists, inspect it and choose another name rather than replacing it.

Introduce and reverse one bad instruction

Commit a clearly labeled, deliberately incorrect sentence in the fixture runbook, such as claiming that enable always starts a service immediately. Record that commit's actual hash. Revert it with git revert --no-edit ACTUAL_HASH, then inspect the resulting history and file.

Do not use reset --hard or force push for this shared-history rehearsal. The original bad commit and the corrective commit should both remain inspectable. If a conflict occurs, explain the intended final sentence before resolving it.

You can capture the deliberate bad commit without typing a copied placeholder: immediately after that commit run study_bad_commit=$(git rev-parse HEAD), inspect it with git show "$study_bad_commit", then run git revert --no-edit "$study_bad_commit". The final runbook should omit the wrong sentence, while git log --oneline -3 preserves the mistake and the reversal. This is the same history-preserving operation taught in the bite, now applied to a reviewed technical instruction.

Checkpoint and revision

Provide the reviewed diff, the reason the bad instruction was wrong, the revert commit, and a clean final status. Explain what would differ for an unstaged edit that had never been committed.

Handy revision: working tree is current files; index is next snapshot; commit is recorded history; branch is a reference; revert is a new corrective commit.

Retain the small repository as evidence or remove it after confirming it has no unrelated work. This completes a foundation milestone: a concise runbook backed by observations, a reviewable change, and a recovery trail. Use these habits in the next personal-site guided project; this exercise does not claim production operating experience.

Sources

Primary references: Git revert↗; Git status↗.