双分支合并推送

双分支同步的常见痛点

当团队用“副分支开发+主分支发布”的双分支模型时，常遇到这类问题：dev 分支写完功能想同步到 main，手动操作容易忘步骤——比如推了副分支忘切主分支合并，或者合并时用 --ff 把副分支历史压成一条线，主分支看不到清晰的合并节点；要是不小心用了 --force，还可能覆盖远程已有提交，把团队协作冲乱。另外，合并完忘了切回工作分支，后续改代码时才发现自己在 main 上，平白多了额外操作。

技能如何解决这些问题

这个技能的核心是标准化双分支交接流程，确保工作同步到主分支发布线的同时，保留两端历史和清晰的合并提交。

核心能力

• 自动识别分支：通过 git symbolic-ref refs/remotes/origin/HEAD 或用户指定确定主分支（优先 main，其次 master），当前非主分支即视为副分支（优先 dev，其次 develop）；
• 保留双端历史：用 git merge --no-ff 在主分支生成明确的合并提交，不丢失副分支的提交记录；
• 规范提交行为：副分支改动按 Conventional Commit 格式提交，禁止 --no-verify 跳过钩子；
• 最终状态对齐：全流程结束后自动切回副分支，保证用户仍停留在工作分支。

关键步骤

1. 前置检查：用 git status --short、git branch --show-current、git remote -v 确认工作区干净，不丢弃任何本地改动；
2. 分支切换与拉取：切到副分支（若已在此分支则跳过），用 git pull --ff-only origin 同步最新代码；
3. 副分支提交与推送：有本地改动则 git add 后按 Conventional Commit 提交，再 git push origin <副分支>；被拒时先 git fetch 查差异，绝不强制推送；
4. 主分支合并：切到主分支，git pull --ff-only origin 同步，若主分支未含副分支则用 git merge --no-ff 合并并写清合并说明；
5. 主分支推送与收尾：git push origin <主分支> 后切回副分支，汇报副分支 SHA、主分支合并 SHA 和已推送分支。

适用边界与注意点

这个技能只处理标准双分支同步，以下场景请换用其他工具：

• 单分支提交推送：直接用 git-pushing-fast 更合适；
• 强制推送/改写历史：比如 git push --force、rebase，这类操作会破坏协作历史，技能明确禁止；
• 从历史生成汇总：比如写周报，需要用 git-weekly-report；
• 代码评审：技能只负责合并推送流程，不涉及代码内容检查。

另外，合并时若遇到冲突，技能会立即停止操作并列出需要你手动解决的文件，避免自动合并导致的错误覆盖。