长期特性分支不能只靠 git merge origin/main，因为会堆积大量无意义的合并提交、导致历史臃肿难读，并在主干频繁变更时反复引发相同冲突；应优先用 git rebase origin/main 保持线性历史、逐次解决差异，但若该分支已被他人基于开发，则必须改用 merge 避免破坏协作。

长期特性分支为什么不能只靠 git merge origin/main

因为 merge 会不断堆积无意义的“合并提交”，让历史变得臃肿难读，且容易掩盖真实开发节奏。更严重的是，当主干（main）频繁变动、尤其包含大量重构或接口调整时，单次 merge 可能引入大量冲突，而这些冲突在后续开发中反复出现——你不是在解决一次问题，是在重复解决同一类问题。

git rebase origin/main 是更可控的同步方式

rebase 把你本地的提交“重放”到 origin/main 最新基础上，保持线性历史，也让你每次只面对当前改动与主干的差异，而不是累积的全部变更。

• 执行前确保已 fetch： git fetch origin
• 切换到你的长期分支（如 feat/payment-gateway-v2），再运行：git rebase origin/main
• 如果出现冲突，解决后用 git add . 标记，再 git rebase --continue
• 推送需强制（因提交哈希已变）：git push --force-with-lease origin feat/payment-gateway-v2

注意：--force-with-lease 比 --force 安全，它会拒绝覆盖别人新推上去的提交。

MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub

使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...

下载

哪些情况必须停用 rebase，改用 merge

当你这个分支已被其他同事基于它继续开发（比如有人从 feat/payment-gateway-v2 拉出了 feat/payment-webhook），那就不能再 rebase——否则会破坏他们的分支基础。

• 此时应改用 git merge origin/main，并写明合并目的，例如：merge main to sync refactoring in auth layer
• 合并前先 git log --oneline origin/main..HEAD 确认自己有哪些未同步提交，避免遗漏
• 如果合并后发现功能异常，优先检查是否是 origin/main 中刚引入的 breaking change，而不是归咎于自己的代码

长期分支的存活底线：每周至少同步一次

超过 7 天未同步 origin/main 的长期分支，风险陡增——不是技术上做不到，而是人容易忽略中间发生的 API 删除、依赖升级、CI 配置变更等隐性破坏点。建议把同步动作纳入日常开发 checklist，而不是等到 PR 提交前才做。

真正麻烦的从来不是命令怎么敲，而是忘了“这个分支其实已经脱离主干太久”。