Recover safely and defend the complete change

Revert is a new change, not an eraser

Use git log --oneline to find the exact repair commit created in Chapter 2. In this isolated exercise only, run git revert --no-edit REPAIR_COMMIT, replacing the placeholder with that inspected commit ID. This appends a commit reversing the repair. It does not erase the earlier commit from history.

Run the tests again. The exactly-10 boundary fails because you deliberately reintroduced the starting defect. Capture that failure. Reverting can restore undesirable behavior; it is not synonymous with “make safe.” Recovery must be verified against the requirement and the business impact.

Next inspect the revert commit ID and revert that commit. The repair returns through another new commit. All five tests pass. This is a useful demonstration when changes are already shared: recovery is visible and reviewable without rewriting peers' existing history. Conflicts are still possible in real repositories; the tiny fixture does not establish universal automatic reversibility.

Understand the risk of alternatives

History-changing commands and working-tree discard operations solve different problems. Do not choose them just because someone calls them “undo.” Ask whether a change is committed, shared, staged, unstaged or untracked; identify the exact target and recoverability. Destructive resets, broad clean operations and force pushes are intentionally absent from this lab.

A local commit can help preserve a deliberate checkpoint, but a repository stored on one disk is not an independent backup. A remote also is not a secret scrubber or a retention policy. Decide where authorized backups live and how you would recover the repository and its dependencies after losing the machine.

Investigate a misleading passing check

Imagine that the repaired working directory passes but the peer clone fails at 10. List at least three plausible causes before changing anything: the repair was never staged; the staged snapshot predated the final edit; the peer checked out an earlier commit or branch. Compare commit IDs, cached diffs, status and the peer's file content.

Another trap is changing assertEqual(classify_free(10), 'OK') to expect REVIEW. That can produce passing tests by abandoning the written requirement. Review the test diff as carefully as the production diff. A changed expected value needs a justified specification change, not merely a desire for green output.

Project A — Catch the broad replacement defect

In a separate temporary copy, replace every occurrence of the text <= 10 with < 10. Predict the endpoint result first. The input-validation expression contains <= 100, so the broad edit changes it to < 100. The 100 endpoint test catches this regression even if the 10 boundary test now passes.

Repair only the intended return expression, rerun all five tests and show the diff. This exercise explains why editing, testing and review are not interchangeable. A correct local change can become an incorrect mechanical rewrite if the pattern does not identify the intended syntax boundary.

Project B — Submit a realistic pull-request brief

Write a review artifact with: a one-sentence requirement; a reproducible failing baseline; the minimal fix; literal expected boundary results; runtime versions; a list of negative inputs; and unverified operational questions. Include the peer-clone commit ID and its test output. State that input is synthetic and no production collector was touched.

Propose a service-specific release workflow: branch creation, restricted destination, review, automated tests, independent clone or clean runner, merge approval and rollback verification. Do not claim it is configured on GitHub until you actually inspect the intended account and repository settings with authorization.

Project C — Resolve a two-part conflict

Extend the scope document to separate visibility from recursion. One branch changes visibility; another changes recursion. Decide whether Git merges the text automatically and whether that automatic result is approved. An automatic merge can combine two individually plausible changes into an unapproved broader population.

Write the required resulting scope and an acceptance matrix before integrating. Include visible top-level, hidden top-level, visible nested and symlink cases. If there is no collector implementation in this repository, label the matrix a proposal, not executed coverage. Textual integration and behavioral verification are distinct achievements.

Acceptance and references

Deliver the initial failing result, the reviewed repair commit, passing five-test output, staging demonstration, independent clone, conflict decision and verified revert/revert-of-revert history. Your review must explain why ignores do not protect already committed secrets and why a staged snapshot can differ from tested working content.

Consult the official Git documentation for git add, git diff, git restore, git switch, git fetch, git merge, git revert and gitignore. For real hosting, consult GitHub's official pull-request, authentication and branch-protection documentation for the actual account setup. No purchased book is required to finish this standalone exercise.

Official references: staging and recording changes, restore, ignore patterns and GitHub pull requests.

Transfer project — changed conditions

Use the supplied deliberately broken capacity exercise in a new repository. Record failing output, make the minimal repair and rerun tests. Inspect staged changes before committing. Add a review note explaining the requirement, evidence and remaining assumptions about numeric validation. Then simulate an upstream change to the same function and resolve the conflict by preserving intended behavior and rerunning tests, not by blindly choosing one entire file.

Practical assessment rubric

Score each dimension 0–2: 0 = absent or materially incorrect; 1 = partly correct with an unresolved gap; 2 = correct, explicit and supported by the supplied evidence or an actual labeled lab result.

1. Evidence/model: identify the relevant entities, inputs, assumptions and boundaries without inventing facts.
2. Main result: derive the case-specific expected result, calculation or decision and show the intermediate reasoning.
3. Failure/boundary: test the changed condition and explain why the original conclusion does or does not transfer.
4. Verification: supply reproducible steps and expected/observed results; label manual traces as manual, not executed.
5. Communication/safety: explain limitations, owners and a proportionate next action without unsafe or unnecessary access.

Target: at least 8/10, with no zero in main result or communication/safety. This is a local learning rubric, not an accredited certification standard. A written/manual solution demonstrates reasoning only; operational competence additionally requires the relevant executable lab in an authorized environment. The native multiple-choice score is separate and does not automatically grade this rubric.

Submission template

• My input/evidence and assumptions:
• Expected result with calculations or trace:
• My implementation/decision and justification:
• Changed-condition result:
• Observed execution, or explicitly labeled manual trace:
• Failure and recovery evidence:
• Unverified limitation and next action:
• Self-score with evidence for each dimension:

Remediation

If the main result is wrong, reconstruct the supplied case from the raw inputs before changing code or controls. If the boundary case is wrong, identify the assumption that changed and rerun both the original and changed case. If verification is missing, do not convert a prediction into an observed result. Reattempt the transfer task without copying the worked solution, then explain it to another person.

Official reference for further study

Assessment: explain your decisions

Choose an answer and write your reason before opening each explanation. Then explain why the other choices do not fit the evidence. Use missed questions to revisit the lesson. This knowledge check is only one part of assessment: complete the practical transfer project as well. It does not predict certification-exam success.

1. What does a commit record?

1. The staged snapshot
2. Every future edit
3. The screen display

Answer and explanation

The staged snapshot — Commits use the staged content.

2. Does .gitignore erase tracked secrets from history?

1. Yes
2. No
3. Only after renaming

Answer and explanation

No — Ignoring is not history removal or credential revocation.

3. Which command inspects staged changes?

1. git status –short only
2. git push
3. git diff –cached

Answer and explanation

git diff –cached — The cached diff compares the staged snapshot.

4. You stage a repair and then edit the same file again. What does the next ordinary commit contain?

1. The staged snapshot, not automatically the later unstaged edit.
2. Every saved change in the working directory.
3. Only the last edit made in the editor.

Answer and explanation

The staged snapshot, not automatically the later unstaged edit. — The index is a separate proposed snapshot. Inspect both git diff and git diff –cached, and verify that the tested content matches the intended commit before sharing.

5. You want to unstage capacity.py while retaining its working edit. Which operation fits?

1. git restore — capacity.py
2. git restore –staged — capacity.py
3. Delete and recreate the repository.

Answer and explanation

git restore –staged — capacity.py — The –staged form changes the index without discarding the working edit. A worktree restore can overwrite that edit. Identify the location and recoverability before using an undo command.

6. Reverting the repair makes the exactly-10 test fail again. What should the reviewer conclude?

1. Revert failed because it did not delete history.
2. The tests must be changed to agree with the reverted code.
3. The new recovery commit restored the known defect; recovery behavior still needs verification.

Answer and explanation

The new recovery commit restored the known defect; recovery behavior still needs verification. — Revert adds a reversing change; it is not automatically a safe resulting state. In this lab, reverting the revert restores the repair through visible history, and independent tests confirm the behavior.

7. Which test exposes the reported bug?

1. Exactly 10% should return OK.
2. Only 9% should return Alert.
3. Only 11% should return OK.

Answer and explanation

Exactly 10% should return OK. — The old and new comparisons agree at 9 and 11. The exact boundary distinguishes them.

8. How should the unrelated configuration rename be treated?

1. Hide it in the commit message.
2. Remove it from this fix or review it as a separate justified change.
3. Keep it because any green test suite proves compatibility.

Answer and explanation

Remove it from this fix or review it as a separate justified change. — Unrelated changes complicate review and can introduce untested behavior beyond the stated requirement.

9. After resolving a merge conflict, what evidence is needed?

1. Assume the absence of conflict markers proves correctness.
2. Delete the regression test.
3. Review the merged behavior and rerun relevant tests.

Answer and explanation

Review the merged behavior and rerun relevant tests. — Syntactically resolved files can still implement the wrong logic. Behavioral verification remains necessary.

Open the scored course assessment to use the existing practice-test engine. Earlier attempts remain part of your history.