GitHub Flow下多并行功能分支开发如何避免git合并冲突

这类冲突的本质是两个功能分支都基于同一旧版本的主干分支修改了连续的相邻代码行，Git无法自动判断合并优先级触发冲突，可通过以下方案规避或提前处理：

• 合并前同步主干最新代码
  所有功能分支提交PR前，必须先拉取main分支的最新提交，通过git merge origin/main或git rebase origin/main将主干更新同步到本地分支，在本地提前解决冲突后再提交PR。示例场景中开发者B在合并black-font分支前，先同步已经合入red-background的main分支，本地修改冲突保留background-color: red+color: black的正确结果后再提交，合并到main时不会再触发冲突。
• 优化任务拆分与协同规则
  功能拆分时尽量保证不同分支的修改范围不重叠，样式类开发可按组件、属性类别划分任务，避免多人同时修改同个选择器下的连续样式规则。如果确实需要修改同一段代码，提前同步开发进度，避免各自独立开发多日后才合并。
• 约定PR合并顺序
  存在关联的多个功能修改，提前约定合并节奏，后开发的功能分支基于已经合入主干的前序功能代码拉取，而非所有分支都基于同一旧版本主干创建。示例场景可先合入背景色修改的PR，开发者B再基于最新main拉取分支开发字体修改需求，从源头避免冲突。

需要注意的是，完全100%消除合并冲突不可能实现，以上方案本质是将冲突解决时机从合并主干的阶段提前到本地开发阶段，降低对主干分支稳定性的影响。

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