Chapter C63 · Interactive Course
Keep work recoverable and shareable
Checkpoints, worktrees, conflicts, handoff notes, pull requests and release verification.
Core Learning Concept
Prepare a handoff that preserves both the change and the evidence. Identify the checkout and recorded state, resolve conflicts according to intended behavior, and summarize relevant checks and limitations. Separate review readiness from release readiness, and state what environment-specific verification remains.
What You’ll Learn in This Chapter
-
Checkpoint before a risky change
Select a recoverable project state.
A checkpoint is a recoverable record made before a change whose reversal could be difficult. It may be an authorized Git commit, backup, or other suitable snapshot. Confirm what it includes and preserve unrelated work. A checkpoint supports recovery; it does not itself verify that later changes are correct.
-
A worktree is a separate checkout
Use isolation to protect parallel edits.
A worktree creates another working checkout associated with a Git repository. It can separate file edits for concurrent tasks while sharing repository history. External databases, services, and ports may still be shared. Check those dependencies before treating a separate checkout as a fully isolated environment.
-
Resolve conflicts by intended behavior
Choose a resolution using both changes' purposes.
Merge conflicts happen when changes overlap across multiple branches. Resolve conflicts by synthesizing intended combined behavior rather than choosing one version blindly. Always test all integrated changes after resolving conflict markers.
-
A handoff includes evidence and limits
Write a compact outcome-oriented note.
A useful handoff states the problem, final change, location, validation, and remaining work. Include enough evidence for another person to continue without repeating the investigation. Distinguish completed checks from assumptions and untested environments. A list of edited files alone does not explain whether the task is done.
-
A pull request is a review proposal
Distinguish proposed integration from merged code.
A pull request proposes merging branch changes into a target codebase. Opening a request does not mean code is merged or deployed. Always review current diffs and automated test runs prior to merging.
-
Release needs environment-specific verification
Separate local success from a running service.
Release verification checks the environment users will actually use: configuration, dependencies, data, routing, and runtime behavior. Local tests and builds provide valuable evidence but do not establish a deployed result. Follow the authorized release workflow and inspect the served version before reporting that users have the repair.
-
Prepare the handoff
Write a patch summary separating checked behavior from unverified environment behavior, with a recovery point and the next review action.
-
Review a small repair
Take a supplied toy repository from a reported bug to a reviewed patch and an honest handoff, keeping local evidence separate from release evidence.