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 MicroBank environment-readiness project; this exercise does not claim production operating experience.

Apply this to MicroBank

Use the reviewed runbook and recovery commit as evidence in the MicroBank readiness project. Keep the practice repository distinct from the implementation repositories. A later real change should use the repository that owns it: application code in MicroBank; infrastructure, configuration, GitOps, and Backstage configuration in Ship Boring Lab. No remote publication is required here.

Keep this observation in the MicroBank readiness project.

Sources

Primary references: Git revert↗; Git status↗.