如何有效减少GitHub中的分支合并冲突

合并冲突本质是两个分支对同一段代码做了不同修改，Git没法自动判断该保留哪份，想要从根源减少冲突，核心是尽量缩小分支间的代码差异、提前同步变更，不要把差异攒到最后合并的时候才处理，具体可以按下面的方法做：

• 高频同步主分支最新代码到功能分支，不要等功能全开发完才做一次合并。建议每天开工前、每次准备提交代码前，都把远端main分支的最新代码拉到本地功能分支，优先用git rebase origin/main做同步，每次只处理最近一两天产生的小范围冲突，比攒几周的差异堆成大冲突好解决得多。
• 控制功能分支的生命周期和改动范围，不要开“长命大分支”。大需求拆成多个独立的小任务，每个小任务对应一个独立分支，单个分支开发周期尽量控制在3天以内，改动文件不要跨太多无关模块。分支存活时间越短、改动范围越聚焦，和主分支产生代码碰撞的概率就越低。
• 团队统一代码格式化、lint规则，消灭无意义的格式类冲突。超过一半的合并冲突根本不是逻辑冲突，只是不同开发者用的格式化工具配置不一样，有人改了缩进、换了换行、自动重排了整个文件的顺序导致的。团队要统一prettier、eslint这类工具的规则，提交代码前自动做格式化，不要顺手修改和自己功能无关的代码格式。
• 协作时提前同步分工，避免多人同时修改同一文件的同一区块。改公共模块、公共配置文件之前，先看下最近谁在改这个文件，提前打个招呼，尽量错峰修改；如果两个人必须改同一段逻辑，就先后提交，不要各改各的攒到合并时才发现撞了改动。
• 不要随意修改全局共享的公共文件。依赖锁文件、全局路由、公共配置、通用组件入口这类文件是冲突重灾区，除非是自己的任务必须改，不要随手调整里面的内容；加依赖、改全局配置尽量和团队同步，集中更新，不要每个人都随手改一笔。
• 合并前先在本地预处理冲突，不要直接提PR等线上提示冲突再处理。功能开发完成准备合并前，先在本地拉取主分支最新代码，提前解决完所有冲突、跑通基础测试再推送，不要把冲突留到合并环节。

注意：就算做了以上操作也不可能完全消灭合并冲突，真遇到冲突的时候不要图省事直接选“保留我方版本”或者“使用对方版本”强行覆盖，一定要逐行核对两边的改动逻辑，确认合并后的代码同时包含两边的有效变更，不然就算暂时把冲突消了，后面也容易出线上bug。

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