committing-and-pushing git:20260831.00488a4A

Immutable. This exact content never changes and is served at /api/v1/blob/e5576f676da324a3.

---
name: committing-and-pushing
description: Commit and push discipline — build before committing, one concern per commit with behavior and structure never mixed, deliberate staging, semantic reconciliation before main advances. Use when committing, pushing, or merging a branch toward main.
---

# Committing and pushing

## Every commit
1. Build before you commit. Run the build and the tests the change touches; a commit
   that does not build is never pushed. A broken commit on a shared branch breaks every
   colleague who pulls it.
2. `git status` and `git diff` first: know exactly what you are committing, and confirm
   every staged change is yours. Stage deliberately — do not sweep in files you did not
   change.
3. One concern per commit, and never behavior and structure in the same one. A commit
   that both moves code and changes what it does cannot be reviewed under one lens —
   the reviewer cannot tell which lines are supposed to change output. Split them:
   structure commits reviewed for direction, behavior commits reviewed for
   correctness. A tangled commit is also permanent damage — it poisons blame, bisect,
   and defect archaeology long after it merges.
4. Message: concise, descriptive, states what the change does. No co-author lines, no
   tool or model attributions, no generated-by noise.
5. Push to your own branch.

## Merging your branch into main
Merging is a semantic integration problem, not a text-selection problem.

When a lane pins an authorized target commit, hold that exact target until the reviewed
candidate lands. If the target moves for unrelated work, stop and report the hold
violation. Do not reconcile or rebuild on the moved target unless the owner explicitly
changes the pin.

1. Merge main into your branch first. Every conflict is resolved on your branch.
2. Resolve conflicts semantically. Never resolve by wholesale accepting ours, theirs,
   or the newer block. For each conflict, determine what each side contributes — read
   the merge base, both sides, callers, and tests — and produce a combination that
   keeps your intended change and every orthogonal behavior main already carries. When
   two behaviors are truly incompatible, stop and send the decision up; do not silently
   choose one.
3. Prove the reconciled branch: build, tests, and the repository's required gates, on
   the branch, after reconciliation.
4. The review that clears the work covers the post-reconciliation result; a review from
   before reconciliation is stale where reconciliation changed semantics.
5. Advancing main is the orchestrator's decision: it happens after the
   orchestrator has cleared the work — the `reviewed-clean` verdict is on
   record, and, for a substantial change (feature-cycle's spirit-review
   definition), the product owner's `--kind verdict` attest is on the goal's
   assignment. A routine change — a wire-spelling fix, not an effort-check-in —
   advances on `reviewed-clean` alone. You execute the mechanics: confirm main
   is an ancestor of the reconciled branch
   (`git merge-base --is-ancestor main <branch>`), then advance main from the
   branch — fast-forward, because the reconciliation already happened on the
   branch.
6. When main moved during reconciliation, merge it in again and re-prove before
   advancing.