commit-push-pr-merge

name	commit-push-pr-merge
description	Commit all working-tree changes in logical units, push the branch, open a PR, wait for checks, and merge to main when green and conflict-free. Use when the user wants to ship the current branch end-to-end (e.g. "ship it", "commit and merge", "get this into main").

Commit → Push → PR → Merge

Ship the current working tree to main in one flow. Stop and report at the first gate that fails — never force a merge.

1. Inspect and group the changes

• Run git status and git diff (plus git diff --stat for an overview) and read the untracked files. Run git log --oneline -5 to match the repo's commit-message style.
• If on main, create a feature branch first (git checkout -b <topic>). Never commit directly to main.
• Group the changes into logical units: one commit per distinct feature, fix, or concern. Unrelated changes (e.g. a new feature + an unrelated bugfix + tooling changes) get separate commits via targeted git add <paths>. If everything serves one change, one commit is fine — don't split artificially.
• Write each message in the repo's style: short imperative subject (~50 chars), body only when the why isn't obvious from the diff.
• Do not commit secrets, .env files, or generated artifacts; if the diff contains one, stop and ask.

2. Push and open the PR

• Push with git push -u origin <branch>. Push the branch you are actually on (git branch --show-current) — don't assume a remembered branch name.
• If the branch already has an open PR (gh pr view --json url,state exits 0 with state OPEN), reuse it. Otherwise create one: gh pr create --base main --title <subject> --body <summary>.
• PR body: a short summary of what changed and why, a test plan (what was run: tests, lint, build), ending with the standard generation footer.

3. Wait for checks

• Watch checks with gh pr checks --watch --fail-fast (give the Bash call a long timeout, e.g. 600000 ms). If a watch could exceed the timeout, poll gh pr checks in a background loop instead and continue when all checks report a terminal state.
• If any check fails: fetch the failing run's log (gh run view <id> --log-failed), report the failure with the relevant output, and stop. Fix only if the user asks.

4. Merge gate and merge

• Verify mergeability: gh pr view --json mergeable,mergeStateStatus. If mergeable is CONFLICTING or the state is DIRTY/BLOCKED, report it and stop — do not rebase or resolve conflicts unprompted.
• Merge only when all checks pass AND there are no conflicts.
• Prefer a merge commit when the branch holds multiple logical commits (gh pr merge --merge --delete-branch); use squash for a single-commit branch (gh pr merge --squash --delete-branch). If the repo disallows the preferred method (check gh repo view --json mergeCommitAllowed,squashMergeAllowed), use whichever is allowed.
• After merging: git checkout main && git pull, and report the merged PR URL.

5. PRs should auto-merge

Once a PR is open, enable auto-merge so it lands as soon as checks pass — don't wait around to merge it by hand. Default to squash + delete the branch: gh pr merge --squash --auto --delete-branch. main has required status checks (build, gitleaks, dependency-review), so auto-merge holds the PR until CI is green before it lands — enabling it right after you open the PR is safe, it will not merge early. (Merging to main then triggers the prod deploy pipeline.)

Always pass --delete-branch. A squash merge rewrites your commits into one new commit on main, so the branch's original commits keep different SHAs — GitHub's main...your-branch compare then shows them as "ahead" and the branch looks like it has unpublished code even though the content is fully merged. Deleting the branch on merge removes that confusion (and the stale copy of any migration file — see below). To confirm nothing is actually unmerged, diff the content, not commits: git diff origin/main origin/<branch> -- <path> per file (empty = identical); a non-empty main...branch compare after a squash is cosmetic.

Repo note (calyflow-app)

Merging to main triggers the Deploy workflow (verify job → Docker build → Cloud Run production deploy). State this in the final report so the user knows a prod deploy is in flight, and mention they can watch it with gh run watch.