git-push-secondary-merge-primarylisted

# Git Push Secondary Merge Primary ## Overview Execute the standard two-branch handoff: finish work on the secondary branch, push it, merge it into the primary branch, push the primary branch, then return to the secondary branch. Use "副分支" for the branch that contains the current work, such as `dev`, `develop`, or another integration branch. Use "主分支" for the protected/release branch, such as `main` or `master`. ## When to Use Use this skill when the user asks for: - Pushing the work branch and then merging into the release branch - A two-branch release-sync workflow such as `dev` → `main` or `develop` → `master` - Finishing a feature on a secondary branch and propagating it to the primary branch - Keeping a clean merge commit on the primary branch while preserving the secondary branch history ## Do Not Use Do not use this skill for: - Single-branch commit/push (use a normal commit + push flow) - Force-pushing, history rewriting, or rebasing operations - Generating reports from git history (use `git-weekly-report` instead) - Reviewing code changes (use `code-reviewer` or `frontend-code-review` instead) ## Branch Detection 1. Prefer explicit branch names from the user. 2. If the user says `dev` or `main` but the repository uses `develop` or `master`, inspect actual branches before choosing. 3. Detect the primary branch with `git symbolic-ref refs/remotes/origin/HEAD` when available. 4. If remote HEAD is unavailable, prefer an existing `main`, then `master`. 5. Detect