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 "secondary branch" for the branch that contains the current work, such as `dev`, `develop`, or another integration branch. Use "primary branch" for the protected/release branch, such as `main` or `master`. This workflow is for safe release-sync handoffs where both branches need to be pushed and the primary branch should preserve a clear merge result. ## 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) ## Instructions Follow the branch detection rules first, then execute the workflow in order. Stop and report the blocker instead of guessing when branch names, merge conflicts, dirty worktrees, or re