咨询Git多同起点分支合并无冲突或减少冲突的策略

针对大量同起点分支合并时冲突频发的问题，以下是几个落地性强的Git策略：

• 提PR前主动同步master分支
  不要等PR过了CI才处理冲突，在提交PR前，先执行git checkout master && git pull拉取最新master，再切回自己的分支执行git merge master（或git rebase master），提前解决冲突后再推送分支、提PR。这样能确保你的分支基于最新的master状态，合并时冲突概率大幅降低。

• 使用集成分支做预合并处理
  不要直接往master分支合并所有PR，先创建一个临时的集成分支（比如integration），将所有待合并的分支逐个合并到这个集成分支上，统一处理所有冲突。确认集成分支稳定后，再一次性合并到master。这种方式能把冲突集中在集成阶段，避免逐个合并到master导致的连锁冲突。

• 严格拆分分支职责，减少文件重叠修改
  要求每个分支只负责单一功能或单一模块的修改，避免多个分支改动同一文件的相同代码块。比如多个分支需要修改配置文件时，可以约定按模块拆分配置段，每个分支只修改对应模块的配置；如果是业务代码，尽量按功能模块划分文件，减少跨分支的代码重叠。

• 用Rebase替代Merge做分支同步
  对于单人开发的分支，提PR前用git rebase master替代git merge master，将你的分支提交变基到最新的master提交之上。这样你的分支提交历史会变成基于最新master的线性历史，合并到master时大概率能触发快进合并（--ff-only），完全避免冲突。注意：如果分支是多人协作开发，不要用rebase，避免改写共享历史。

• 在CI中加入预合并冲突检查
  修改你的CI流程，在执行测试前先自动尝试合并最新的master到当前分支。比如在CI脚本中加入：

  git fetch origin master
  git merge --no-ff origin/master
  

  如果合并失败（存在冲突），直接终止CI并提示开发者先解决冲突。这样能避免CI通过后才发现合并冲突的情况，节省时间。

• 按优先级分批合并分支
  先合并那些修改完全独立（比如改动不同文件、无代码重叠）的分支，这些分支合并后不会影响其他分支。然后让剩下的分支同步最新的master（此时master已经包含了第一批合并的分支内容），解决冲突后再按优先级合并。这种分批处理的方式能逐步缩小冲突范围，减少一次性处理大量冲突的复杂度。

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