记住下面几个原则就好：
1 、只保留 1 个永久性分支 main ，其他分支都是临时分支，在生命周期结束后(合并到 main 分支)就会被删除。
2 、任何线上代码的变化，都不允许直接在已存在的分支中修改，而是通过从 main 分支合并来获取变化。
3 、修改线上代码只能从 main 分支切出来进行修改，修改完成后需要合并回 main 分支。
只要做到这 3 点，特别是第二点，就永远不会有代码冲突。有些团队喜欢搞什么测试分支、预发分支，其实都不需要。CI/CD 的精髓在 tag 而不是分支，通过不同类型的 tag 来实现自动化发布。
 |
1
DrakeXiang Dec 15, 2022
第二点并不能避免冲突，除非所有的分支都是顺序拉取的，否则两个人拉了同一版本的 main ，然后改了同一个文件的同一个地方，后合并的那个肯定会冲突
|
 |
2
xuanbg OP 是的，但在我们一般不会多个人同时改同一个文件。
|
 |
3
DingJZ Dec 16, 2022  1
从分支本身也许能减少一部分问题, 不能避免, 还是要从设计上解决, 模块 /组件划分清晰, 从源头上需求和需求, 分支和分支就不应该冲突, 或者都是很好解决的冲突
|
 |
4
vvhhaaattt Dec 16, 2022 via Android
这叫我想起来 rebase 跟 merge 了。
|
 |
5
penzi Dec 16, 2022 via Android
理想情况是这样的，但这只对自有产品，自己能把控发布节奏的团队有效。并且需要完善的测试 pipeline 和 review 保证有问题的代码最开始就不会进主分支。
对于很多产品来说，不同客户有不同的定制化需求。而且因为工期紧，不可能写测试，不可能仔细 review ，没有时间仔细设计导致不同定制化需求无法合并到主分支。 所以需要有测试分支给测试人员测试，所以需要不同版分支，每个分支都要单独维护。 分支管理流程不是因是果。 |
|
6
penzi Dec 16, 2022 via Android
只要交付给客户的是软件而不是一个在线服务，就不可避免的维护 n 个版本。最简单的比如维护各个版本的 Windows 系统，根本不可能用这套方法解决。
|
 |
8
Chemist Dec 16, 2022 via iPhone
解决冲突并不可怕，所以没必要刻意避免。
|
|
9
xuanbg OP @kyuuseiryuu 解决冲突会耗光我的耐心。。。所以就尽量避免冲突。
|
Select Language