好吧，我也来谈一下如何避免 Git 分支合并时的冲突

[xuanbg]

记住下面几个原则就好：

1 、只保留 1 个永久性分支 main ，其他分支都是临时分支，在生命周期结束后(合并到 main 分支)就会被删除。

2 、任何线上代码的变化，都不允许直接在已存在的分支中修改，而是通过从 main 分支合并来获取变化。

3 、修改线上代码只能从 main 分支切出来进行修改，修改完成后需要合并回 main 分支。

只要做到这 3 点，特别是第二点，就永远不会有代码冲突。有些团队喜欢搞什么测试分支、预发分支，其实都不需要。CI/CD 的精髓在 tag 而不是分支，通过不同类型的 tag 来实现自动化发布。

[DrakeXiang]

第二点并不能避免冲突，除非所有的分支都是顺序拉取的，否则两个人拉了同一版本的 main ，然后改了同一个文件的同一个地方，后合并的那个肯定会冲突

[xuanbg]

是的，但在我们一般不会多个人同时改同一个文件。

[DingJZ]

从分支本身也许能减少一部分问题, 不能避免, 还是要从设计上解决, 模块 /组件划分清晰, 从源头上需求和需求, 分支和分支就不应该冲突, 或者都是很好解决的冲突

[vvhhaaattt]

这叫我想起来 rebase 跟 merge 了。

[maggch97]

理想情况是这样的，但这只对自有产品，自己能把控发布节奏的团队有效。并且需要完善的测试 pipeline 和 review 保证有问题的代码最开始就不会进主分支。


对于很多产品来说，不同客户有不同的定制化需求。而且因为工期紧，不可能写测试，不可能仔细 review ，没有时间仔细设计导致不同定制化需求无法合并到主分支。

所以需要有测试分支给测试人员测试，所以需要不同版分支，每个分支都要单独维护。

分支管理流程不是因是果。

[maggch97]

只要交付给客户的是软件而不是一个在线服务，就不可避免的维护 n 个版本。最简单的比如维护各个版本的 Windows 系统，根本不可能用这套方法解决。

[xuanbg]

@DingJZ 确实，好的软件架构设计本身就能避免很多乱七八糟的问题。我也见过不少糟糕的设计导致一些最佳实践根本没法落地。

[kyuuseiryuu]

解决冲突并不可怕，所以没必要刻意避免。

[xuanbg]

@kyuuseiryuu 解决冲突会耗光我的耐心。。。所以就尽量避免冲突。