如何在合并前修复Git合并冲突？PR工作流优化方案

我太懂这种困扰了——每次把feature分支往master合的时候碰冲突，最后全堆给负责合并的人处理，在GitHub/GitLab这类PR驱动的工作流里真的很别扭。毕竟写代码的人最清楚自己的逻辑，让合并者来啃冲突不仅效率低，还容易出问题。

下面是几种能把冲突处理责任交还给提交者的可行方案：

方案一：提交PR前主动将master合并到feature分支 #

这是最通用也最容易落地的做法，步骤很清晰：

• 切换到你的feature分支：git checkout feature/your-feature
• 拉取远程最新的master代码：git fetch origin master
• 将master合并到当前feature分支：git merge origin/master
• 此时Git会提示冲突文件，打开这些文件手动解决冲突（注意保留正确的业务逻辑）
• 冲突解决后，暂存修改：git add .
• 提交冲突解决的记录：git commit -m "Resolve merge conflicts with latest master"
• 推送到远程feature分支：git push origin feature/your-feature

这么做的好处很明显：你作为代码的编写者，对自己的代码逻辑最熟悉，解决冲突的速度和准确性都远高于不熟悉业务的合并者，而且能确保PR提交时已经是和最新master兼容的状态，合并者只需要做代码审核，不用再处理冲突。

方案二：用变基（Rebase）替代合并，打造更整洁的提交历史 #

如果你的团队偏好干净线性的提交历史，变基会是更好的选择：

• 切换到feature分支：git checkout feature/your-feature
• 拉取最新master代码：git fetch origin master
• 将feature分支变基到最新master：git rebase origin/master
• 遇到冲突时，先手动解决冲突，然后暂存修改：git add .
• 继续变基流程：git rebase --continue
• 因为变基会改写提交历史，需要强制推送到远程分支（推荐用--force-with-lease，比直接--force更安全，能避免覆盖他人的提交）：git push origin feature/your-feature --force-with-lease

变基的核心是把你的feature分支的所有提交，重新“嫁接”到最新的master分支上，让提交历史看起来像是你从最新master开始写的代码，非常清爽。但要注意：必须和团队提前约定好变基的使用规则，避免多人同时操作同一个分支导致的历史混乱。

额外的团队层面优化建议 #

• 在PR模板里明确要求：提交PR前必须同步最新master并解决所有冲突，否则PR不会被审核。
• 用CI工具做自动检查：比如配置GitHub Actions/GitLab CI，当PR发起时自动检测feature分支是否基于最新master，如果不是就直接标记为“需要修改”，倒逼提交者先处理冲突。
• 鼓励小粒度PR：尽量把大功能拆分成多个小PR提交，这样冲突的范围会更小，解决起来更简单，也能降低冲突发生的概率。

内容的提问来源于stack exchange，提问作者umläute