为何解决Pull Request冲突需先合并main分支？

• 让最懂代码的人处理冲突
  你提到的“让功能开发者负责冲突解决”是核心，但还有更深的逻辑：冲突代码是开发者自己实现的，他清楚这段代码的业务意图、依赖关系，解决冲突时能精准判断代码取舍，不会因为不了解feature分支的细节导致隐性bug。如果让main分支维护者处理，很可能因为对业务逻辑不熟悉，修复冲突时破坏原有功能。

• 维护main分支的纯净性与稳定性
  main分支是项目的核心分支，要求每一次合并的代码都是经过验证、可直接运行的。如果直接在合并feature到main时解决冲突，相当于把冲突修复的“临时补丁”直接塞进main分支，一旦修复出错，回滚会牵连之前合并的正常代码。而先在feature分支解决冲突，相当于在隔离环境完成了兼容性验证，确保feature分支本身可用后再合并到main，main的提交历史里只会保留完整的、经过验证的功能代码，不会混杂模糊的冲突修复提交。

• 避免重复冲突与合并混乱
  如果直接在main合并时解决冲突，后续其他开发者拉取最新main分支后，和自己的feature分支合并时，大概率会重复遇到相同冲突。而先把main合并到feature分支，解决完冲突后，feature分支已完全同步main的最新代码，此时合并回main时基本是快进合并（如果main没有新提交），不会再产生冲突，也不会在main里留下多余的合并提交，反而能让提交历史更线性清晰。

• 符合主流分支工作流的设计逻辑
  不管是Git Flow还是GitHub Flow这类常用工作流，核心都是让feature分支始终基于最新的main分支开发。先合并main到feature，本质是让feature分支“跟上”main的节奏，确保feature代码和main的最新代码兼容。直接在main合并时解决冲突，相当于跳过了feature分支的前置验证环节，违背了工作流“先隔离验证，再合并核心分支”的设计，会大幅增加main分支的风险。

另外，如果担心合并导致提交历史混乱，可以用git rebase main代替git merge main：在feature分支执行rebase，将你的提交重新基于最新的main分支，解决冲突后推送到远程，合并到main时就是快进合并，提交历史会完全线性，不会有多余的合并节点。

内容的提问来源于stack exchange，提问作者CX_Lin