git-push-secondary-merge-primary-cn

Git push secondary branch and merge primary branch

Overview

Execute the standard two-branch handoff workflow: complete work on the secondary branch and push it, then merge into the primary branch and push, and finally switch back to the secondary branch.

• secondary branch: the branch carrying the current work, such as dev、develop or other integration branches.
• primary branch: the protected release branch, such as main or master。

This workflow is suitable for release synchronization scenarios that require pushing both the secondary branch and the primary branch, while preserving a clean merge result on the primary branch as much as possible.

When to use

Use this skill when the user requests the following operations:

• Push the working branch and then merge it into the release branch
• Two-branch synchronized release workflow, for example dev → main or develop → master
• After completing a feature on the secondary branch, synchronize it to the primary branch
• Preserve a clean merge commit on the primary branch while not losing the commit history of the secondary branch

Do not use

Do not use this skill in the following scenarios:

• Single-branch commit/push (use the normal commit + push workflow)
• Force push, history rewriting, or rebase operations
• Generate a summary report from Git history (please use git-weekly-report-cn）
• Review code changes (please use code-reviewer or frontend-code-review）

Usage instructions

First determine the primary branch and secondary branch according to the branch identification rules, then execute in workflow order. When encountering unclear branch names, merge conflicts, a dirty working tree, or a rejected push that cannot be handled safely, stop and explain the blocking reason; do not guess and execute.

Branch identification

1. Prefer the branch name explicitly specified by the user.
2. When the user says dev or main, but the repository actually uses develop or master , first verify the actual branches before choosing.
3. Prefer identifying the primary branch via git symbolic-ref refs/remotes/origin/HEAD .
4. When the remote HEAD is unavailable, prefer the existing main, then master。
5. If the current branch is not the primary branch, treat it as the secondary branch.
6. If currently already on the primary branch and no secondary branch is specified, prefer the existing dev, then develop。
7. If it still cannot be determined safely, ask the user for the primary branch and secondary branch names.

Usage instructions

Strictly execute the following workflow, preserve user changes, and stop when branch, merge, or push conditions are unsafe.

Workflow

1. Check repository status.

   • Run git status --short、git branch --show-current、git remote -v。
   • to confirm the working tree belongs to the target repository.
   • Do not discard or roll back user changes.
   • Determine <secondary_branch> and <primary_branch>。

2. according to the branch identification rules. Switch the work to <secondary_branch>。

   • If already on <secondary_branch> , continue.
   • When currently on another branch and the working tree has uncommitted changes, execute only if Git allows a clean switch; otherwise stop and explain the blocking reason to the user.
   • When currently on another clean branch, execute git checkout <secondary_branch> and git pull --ff-only origin <secondary_branch>。

3. If <secondary_branch> has local changes, commit them first.

   • Use git add Stage related changes unless the user requests a smaller scope.
   • Generate a commit message conforming to Conventional Commits: English type(scope): prefix + colon followed by a Chinese summary.
   • Not allowed to use --no-verify。
   • If hooks or validation fail, fix the issues first before committing.
   • If <secondary_branch> has no local changes, skip the commit and go directly to the push step.

4. Push <secondary_branch>。

   • Execute git push origin <secondary_branch>。
   • If the push is rejected due to remote updates, first git fetch and review before retrying; do not force push unless the user explicitly requests it.

5. Merge into <primary_branch>。

   • Execute git checkout <primary_branch>。
   • Execute git pull --ff-only origin <primary_branch>。
   • When <primary_branch> does not include <secondary_branch> , use git merge --no-ff <secondary_branch> -m "chore(<primary_branch>): 合并 <secondary_branch> 到 <primary_branch>" to preserve the merge commit.
   • If a merge conflict occurs, stop immediately and list the files the user needs to resolve.

6. Push <primary_branch>。

   • Execute git push origin <primary_branch>。

7. Switch back to <secondary_branch>。

   • Execute git checkout <secondary_branch>。
   • Via git status --short and git branch --show-current to double-check.
   • The final branch must be <secondary_branch>。
   • Report the sub-branch commit SHA, (if present) the main branch merge commit SHA, the pushed branches, and the final branch.

Report

Keep the final reply concise. Include the successfully pushed branches and commit hashes. If the host application supports Git instructions, issue the relevant instructions only after the corresponding Git action succeeds.