finishing-a-development-branch

Finishing a Development Branch

Confirm the final change has completed the project's independent quality-check and required checks. Evidence must describe the current tree: rerun affected verification after material edits or integration changes, and report unresolved failures. Do not add another whole-branch review or repeat an unchanged successful test suite merely to follow this skill.

Determine the repository, branch, base, worktree ownership, and uncommitted changes with read-only Git commands. Verify the intended target from the plan, upstream, or conversation before integrating.

Follow the integration action already authorized by the user. The design approval already covers commits, feature-branch pushes, creating the PR and the merge. First, if the project's rules require the user's approval for the merge, or the merge automatically releases, publishes or deploys to production - an environment that customers or users rely on (exception X2; an automatic deploy to an environment for checking behavior (such as staging) that does not touch production - the production database, live payments, or sending to real customers and the like - is not X2; judge by the effect on customers or users, not by the name) - finish the reviewable result and put that question in the final message. Only an answer to that item, or an instruction that names the operation and its target (range), counts as an X2 OK - not the design approval, a generic "continue", or an instruction that names no range. Otherwise look at the deviations from the design - both the spec / plan record and the PR body's deviation section. If there are none, merge with the project's merge procedure once quality-check is complete. If there are any, they change what was approved: finish everything else but create the quality-check flag only after the user's confirmation, ask in the final message as a separate decision ("merge with these deviations?"), and merge after the user's confirmation. A deviation that appears after that confirmation needs a new confirmation. Do not present an approval menu again. End with the final message of documents/development/development-policy.md §1.0 "承認後の進め方".

For a project that promotes main to a production branch (release or similar), the X2 question covers everything that goes out (§1.0 "承認後の進め方" 8). Before asking, run git fetch origin and fix the end SHA of the source. List the PRs not yet promoted up to that SHA: with merge-commit promotion, git log --first-parent --oneline origin/<release>..<SHA>; with squash promotion, main's commits never become ancestors of the production branch, so start from the previous source (the SHA recorded in the last promotion PR, or the first-parent main commit whose tree equals origin/<release>^{tree}); if no starting point is found, do not guess a list - write that it was not found in the final message. Show the list and the short SHA in the final message. As for any X2 OK, only an answer to the item that shows the list and the SHA, or an instruction that names the operation and the range, counts (on a "promote it" that names no range, build the list and the SHA and ask). Promote exactly that SHA; anything that lands before or after the OK stays out. When the promotion goes through a PR, do not use main as its head (push a temporary branch at the SHA and use it, for example git push origin <SHA>:refs/heads/promote/<short SHA>), or merge with gh pr merge --match-head-commit <SHA>. With squash promotion, write the source SHA in the promotion PR body (the next starting point). When this PR is not merged yet, add "this PR (after merge)" to the list; after the merge, if the first-parent range <the SHA you asked with>..<this PR's merge commit> holds only this PR, use that merge commit as the end, otherwise rebuild the list and ask again. After the OK, the AI merges and promotes; do not hand those operations back. The commands depend on the merge method: the project's own procedure holds the exact steps.