Repair on a branch and commit what you actually reviewed

A branch names a line of work, not a separate backup drive

A branch is a movable reference in repository history. Switching branches changes the checked-out tracked content when Git can do so safely. Untracked and some uncommitted changes can remain across switches; branch creation alone does not package them into a backup. Inspect status and preserve real work before switching.

Create the repair branch:

git switch -c fix/capacity-boundary
git status --short

In your editor, change only the return expression from percent <= 10 to percent < 10. Leave the validation rule unchanged. Run python -m unittest -v: all five tests should pass. Review git diff -- capacity.py. The behavioral repair is a one-character operator change with meaningful consequences at a requirement boundary.

Small diffs can be high impact. A review should explain why the change is correct, not infer safety from its size. The three neighboring inputs—9, 10 and 11—separate the strict rule from the inclusive defect. The endpoint and invalid-type tests help catch unintended changes elsewhere.

Demonstrate a staged snapshot

git add -- capacity.py
git show :capacity.py
git diff --cached -- capacity.py

Now add the harmless comment # Unstaged local review note. at the end of the working file using your editor. Do not stage it yet. Compare:

git status --short
git diff -- capacity.py
git diff --cached -- capacity.py

Expect MM capacity.py. The cached diff contains the operator repair but not the later comment; the unstaged diff contains the comment. If you committed immediately, the repair would be committed but the comment would remain outside that commit. This is intentional Git behavior, not lost data.

Unstage without erasing the working edit

git restore --staged -- capacity.py
git status --short

The working repair and comment remain, but the index no longer proposes those changes. This is not the same as git restore -- capacity.py, which can overwrite working-tree content. Do not run worktree-discarding variants casually. Ask which location you intend to change, what is recoverable and whether the file contains someone else's uncommitted work.

For this exercise, keep the harmless comment, stage the full intended change again, inspect it and test it:

git add -- capacity.py
git diff --cached -- capacity.py
git diff --cached --check
python -m unittest -v
git commit -m 'Fix strict below-10 capacity boundary'
git status --short

The untracked scratch note may still appear. That is fine if deliberately excluded; explain it. A clean tracked diff does not mean every file in the directory was committed. To verify exactly what a colleague receives, use an independent clone later rather than relying only on your working directory.

Write the change review before merging

Prepare a short review brief: requirement, observed failure, change, independent tests, unchanged behavior and limits. For this repair, record 9→REVIEW, 10→OK, 11→OK, valid endpoints and rejected non-integer/out-of-range values. Mention that no collection adapter, device health check or live infrastructure integration was added.

Do not attach real inventory, passwords or environment files to a public issue. A reviewable synthetic fixture can demonstrate the defect without revealing an organization's data. If a secret has already been published, involve the appropriate owner and revoke or rotate it; deleting the visible line is not proof that old copies disappeared.

Bring the reviewed repair into main

git switch main
git merge --ff-only fix/capacity-boundary
python -m unittest -v
git log --oneline -4

With the exercise's unchanged main history, the merge fast-forwards. --ff-only refuses a divergent situation instead of silently creating a merge you have not reviewed. If it refuses, inspect the histories and decide on a deliberate merge or other approved workflow. Do not use a force operation merely to reproduce the screenshot or command transcript.

Evidence laboratory — attempt before reading the solution

Requirement: alert below 10% free space, not at exactly 10%. Current function returns Alert when percent <= 10. Existing tests cover 9 and 11 only. A proposed patch changes <= to <, but also renames an unrelated configuration key. Before editing, write the missing regression test, predict its result on the old code and define the desired diff.

Official reference for further study