Use a daily Git gate for branch, commit, diff and merge

Git can succeed while the change is still unsupported

A small coupon-rounding change sits on a topic branch. The branch name looks reasonable, the branch has a commit, and its local check passes. Three questions are still unresolved: what target point the branch is actually based on, what delta the recorded snapshot really carries, and how the integrated state behaves after the target has moved.

This lesson turns branch context, staging, diff, commit, and merge into an evidence gate, not a command checklist. The deliverable is Daily Git Change Gate Record v1. It records the selected base/target context, the reviewable delta, the commit boundary, verification before and after integration, residual limitations, and a bounded human decision.

A clean worktree, a neat commit, or a conflict-free merge is evidence about Git state and Git operations. None of those signals alone proves behavioral correctness or acceptance readiness.

Different support, same evidence bar

The Foundation route makes branch context, comparison boundaries, and commit snapshots explicit before the guided case.

The Repair route returns only to the first broken distinction. If you can identify the target but review the wrong comparison, repair focuses on the comparison and its evidence rather than replaying the whole lesson.

The Experienced / Fast Path compresses syntax, not the artifact or verification standard. Frequent Git use does not make a branch name, commit message, or merge result authoritative.

Self-check: can you show what the topic branch changes relative to the current target? Can you show that the commit snapshot is the intended review unit? Do you have independent evidence from the integrated state? If any answer depends on memory, the gate is still open.

Mental model: five separate boundaries

Branch/base context identifies the change location and ancestry. A well-named branch does not prove it started from the intended base.

Worktree/index context identifies what lives outside history, in the index, and in recorded commits. Staged is a state label, not an intent label.

Diff context must match the question being asked. “I looked at a diff” is incomplete unless the compared states are known.

Commit context records an index snapshot. A commit message describes intent but is not an oracle for the snapshot contents.

Integration context begins after histories are combined. A successful merge establishes Git-level integration; behavioral evidence for the integrated state is a separate claim.

The gate closes with a human ACCEPT, MODIFY, REJECT, or BOUNDED_DEFER, plus rationale, limitation, and a non-claim.

Building Daily Git Change Gate Record v1

Build the record from observable evidence toward a decision:

1. Base and target: record repository identity, topic ref, target ref, HEAD, and merge-base or equivalent ancestry evidence.
2. Observed boundaries: capture worktree/index state and the comparison used for review. Do not hide an unrelated or unresolved delta.
3. Task-relevant diff: provide a locator or reproducible observation that exposes the changed-content boundary relevant to the task.
4. Commit intent: show why the recorded snapshot is the intended review unit; commit existence and message quality are insufficient.
5. Pre-integration verification: record check, result, covered state, and limitation.
6. Integration: record the method, target state, and Git result.
7. Post-integration verification: validate the integrated state rather than automatically reusing pre-merge evidence.
8. Decision: record the human decision, residual risk, non-claim, and material support/AI disclosure when applicable.

The gate is evidence-complete, not command-count complete.

Deep explanation: comparison choice defines what you can claim

Git exposes several states. git diff can compare worktree, index, and commits depending on its arguments. Therefore a diff is meaningful only when the compared states answer the bounded question.

The same discipline applies to commits. A commit records the selected index snapshot. If unrelated content is in the index, a successful commit records it too. If a required change remains only in the worktree, the commit can be incomplete while still succeeding.

A merge combines histories. A conflict-free merge means the operation did not require a particular kind of conflict resolution; it does not establish behavioral compatibility. A newer target-side change can combine cleanly yet alter the behavior that the topic branch assumed.

The lesson diagram is therefore a loop: establish context → inspect boundary → bound diff → commit snapshot → verify → integrate → verify integrated state → human decision. There is no direct arrow from “Git success” to “accepted.”

Worked example: documentation change with generated metadata

Suppose the bounded task is to rename a command-line flag in user documentation. The topic snapshot changes docs/usage.md and also changes a generated documentation index. The index is not automatically in or out of scope: the record needs evidence such as the generator rule, project policy, or a reproducible build showing whether that file belongs to the same review unit.

A defensible record identifies the base and target, exposes the changed paths, states the comparison used, and records the scope basis for each material delta. If scope authority is missing, the record should preserve that uncertainty instead of guessing from a filename, staging state, or commit message.

If the target has moved since the topic began, record pre-integration behavior, the actual Git integration result, and a fresh integrated-state check as three separate observations. Do not predict the integrated result from a clean status, a successful command, or the topic-side check; let the new evidence determine the bounded decision.

Seductive failure modes

“The branch is right, so the base is right.” Branch naming does not prove ancestry. Record target/ref and ancestry evidence.

“Status is clean, so it is ready.” Clean status does not prove that HEAD contains the correct change or sufficient verification.

“The commit message names the task, so the commit is the task.” Inspect the snapshot diff.

“The diff is small, so it is safe.” Size is not correctness evidence; inspect scope and behavior.

“The merge had no conflicts, so integration is safe.” Run an independent check on the integrated state.

“AI says the change is low risk.” AI may suggest probes or hypotheses, but evidence and the final decision must be independently validated.

Map professional workflows to the same invariants

Your team may use trunk-based development, short-lived branches, worktrees, pull requests, merge queues, or internal tooling. This lesson does not mandate one branching model.

Keep the invariants: context and target are identifiable; changed content is reviewable; commit and integration claims bind to real snapshots; verification binds to its state; integrated state gets new evidence; and human judgment plus limitations remain explicit.

A different command sequence or internal artifact is acceptable if it preserves those invariants. Advanced history rewriting, backport, and release-line policy belong to FND-010; full project-state handoff is not re-taught here.

Trade-offs without workflow dogma

Some repositories need only a direct topic/target comparison. Others add generated files, submodules, or multiple worktrees that must enter the evidence boundary. The claim determines the required evidence.

One commit or several? No universal count is required. The review unit must remain inspectable and must not hide unrelated scope.

Merge or rebase? This lesson does not choose a universal policy. Use the project policy, then verify the resulting integrated state.

Accept or bounded defer? If technical evidence is sound but scope authority is missing for a delta, a bounded defer can be safer than guessing. State the missing evidence and the bounded scope of the deferral.

Guided practice and changed-context transfer

In FND009-LAB1, create the local fixture and capture the initial evidence before changing the repository. Read the task brief, inspect topic/target/base context, review the exact change boundary, and record the pre-integration check. Then complete the artifact. No command sequence is mandatory; the evidence fields are.

S2 requires a Daily Git Change Gate Record v1 with real locators. Narrative-only or command-only submissions are insufficient.

For transfer, an assessor provides a second fixture with a different base and a different staging boundary. Re-observe context, diff, and verification from that case. Do not copy path classifications or integration assumptions from the first case.

Minimum defensible evidence package

The final record includes repository/topic/target/head/base evidence, observed state boundary, task-relevant diff locator, commit snapshot and intent evidence, pre-integration check with covered state, integration result, post-integration check, residual limitation, human decision, and a non-claim.

Evidence must be able to falsify the conclusion. “Everything looks fine” is not evidence. A diff locator, object id, test result, file fingerprint, or equivalent observable artifact can make a bounded claim reviewable.

Material support or AI use must be disclosed when it affects probe choice or interpretation. Tool output is not the final authority.

Assessment from retrieval to transfer

S1 separates branch context, diff boundary, and commit boundary in a compact case.

S2 builds the central artifact from the executable lab and ties blocking conclusions to inspectable evidence.

S3 finds the first unsupported promotion from Git success to correctness or acceptance and proposes a discriminating probe.

S4 chooses one of the four decision enums using the evidence and records a limitation and non-claim.

S5 repeats the method in a changed repository where base, staging, and integration context differ; memorized commands are insufficient.

Technical state/history, traceability, human judgment/limitations, and transfer are critical non-compensatory dimensions.

Sources and freshness boundary

Current technical claims are bounded to official Git documentation: git switch for branch/worktree context, git diff for comparison semantics, git commit for index-snapshot recording, and git merge for history integration and conflict handling. None is used as correctness or release authority.

The locked sources were retrieved on 2026-09-02 and are due for review on 2026-10-17. No refresh is due at this authoring stage. Reverification is required if a source materially changes, review_due expires, or authoring introduces a new current technical claim outside the locked research map.

The MAKNOW evidence gate itself is a curriculum DESIGN claim, not a universal Git workflow rule.