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