这是一个创建于 868 天前的主题，其中的信息可能已经有所发展或是发生改变。
主分支 master:
开发分支：feature1212
测试分支：dev
案例：12 月 12 号有一个迭代（有多个功能）要上线，有两位开发同学参与（ A,B ）同时开发。
目前有两种分支管理模式：
## 方案一：
- 从 master 拉 feature1212 分支
- 开发阶段：开发 A ， 开发 B 共用 feature1212 开发
- 测试阶段：feature1212 merger 到 dev ， dev 进行测试 // 当 dev 分支有变更，会通过自动部署
- 部署线上阶段：feature1212 merge 到 master
## 方案二：
- 从 master 拉 feature1212 分支
- 开发阶段：开发 A ， 开发 B 再分别从 feature1212 拉自己的分支，比如：featue1212A, feature1212B // 1. 共用代码不好复用
- 测试阶段：从自己的开发分支 merge 到 dev // 问题：1. 当 dev 分支有变更，会通过自动部署，导致多次构建 2. 这里可能有冲突，需要解决
- 合并冲突阶段：feature1212A ，feature1212B 分别 merge 到 feature1212 // 问题：1. 这里还要再解决一次冲突
- 部署线上阶段：feature1212 merge 到 master
开发分支：feature1212
测试分支：dev
案例：12 月 12 号有一个迭代（有多个功能）要上线，有两位开发同学参与（ A,B ）同时开发。
目前有两种分支管理模式：
## 方案一：
- 从 master 拉 feature1212 分支
- 开发阶段：开发 A ， 开发 B 共用 feature1212 开发
- 测试阶段：feature1212 merger 到 dev ， dev 进行测试 // 当 dev 分支有变更，会通过自动部署
- 部署线上阶段：feature1212 merge 到 master
## 方案二：
- 从 master 拉 feature1212 分支
- 开发阶段：开发 A ， 开发 B 再分别从 feature1212 拉自己的分支，比如：featue1212A, feature1212B // 1. 共用代码不好复用
- 测试阶段：从自己的开发分支 merge 到 dev // 问题：1. 当 dev 分支有变更，会通过自动部署，导致多次构建 2. 这里可能有冲突，需要解决
- 合并冲突阶段：feature1212A ，feature1212B 分别 merge 到 feature1212 // 问题：1. 这里还要再解决一次冲突
- 部署线上阶段：feature1212 merge 到 master
 |
1
hlwjia 2021-11-30 20:18:15 +08:00
|
 |
2
yl20181003 2021-11-30 23:23:10 +08:00 via Android
git-flow
|
 |
3
gzf6 2021-12-01 08:36:27 +08:00 via Android
Trunk base
|
 |
4
CasualYours 2021-12-01 09:14:53 +08:00
你的这两种方案都有一些问题。
两个方案都没有版本的概念，这样会导致你本次功能上线出现问题后，无法正确回滚至上一版本。方案二不应该在测试后再进行代码合并，测试的永远应该是最后要上线的代码。 我公司通常这么处理的： - 从 master 拉取 release-xxx 作为本次的发布分支 - 再从发布分支中 release-xxx 拉取开发分支 feature1212 - 至于你两种方案中纠结的到底是两个人共用一个开发分支，还是各建一个，我的建议：你们就两个人，没有必要增加分支复杂度，直接公用一个开发分支即可，至于开发中遇到冲突，可以通过频繁的 pull/push 来解决 - 你两种方案中的 dev 分支我认为也没有起到效果，首先测试代码应该和要发布的代码完全一致才有意义，你这里的 dev 分支没有注明检出来源，feature1212 merge 到 dev ，无法保证 feature1212 和 dev 代码一致。正确做法是你应该 feature1212 合并回 release-xxx ，用合并后的发布分支直接测试 - 测试完成后发布分支 release-xxx 部署线上发布 - 发布后出现问题，如果要回滚上一版本，那么直接拿上一版本的发布分支（你这里是 master ）部署线上；如果要紧急修复，那么从 release-xxx 中检出一个 release-xxx-fix 去重复上面的过程 |
 |
5
caixiangyu17 2021-12-01 13:29:58 +08:00  1
其实 trank base + feature toggle 是个挺方便的，省去各种 checkout ，merge ，rebase ，pr 的时间，只不过很多公司都习惯各种 branch+pr
我们最近折中了一下，主要是 pr 比较好查看所有的文件变化。基本上流程就是从 master checkout 一个分支，然后每天早上从 master 用 rebase 的方式 pull 到当前 branch 。有冲突就解决，没有更好。最后完成的时候再从 master 拉一下，如果没冲突，建 pr 直接 rebase 回 master 。省时省力，每天解决的冲突，也不至于太多。 其实只要 pipeline 的测试覆盖率够高，问题一般是不大的。还有就是 pre-push 脚本的检测要尽量和 pipeline 一致，这样可以很高效率解决提交代码之后不去检查 pipeline ，然后还得别人问找提交的人，为啥编译不过了，测试挂了之类的问题 |
 |
6
xz410236056 2021-12-01 14:02:50 +08:00
|
 |
7
MXuD0ng 2021-12-01 16:04:08 +08:00
你这两个方式都是按照人来划分分支的，我觉得可以考虑这样：
如果是大型 feature 要切成小的 feature ， 然后一个 feature 一个分支，两个人开发完了小 feature 就合到开发分支（目的是始终保持开发分支拥有全部代码）， 最后测试直接从开发分支切除测试分支（我不太理解为什么要 merge 到测试分支），然后测试通过后封版，推上线。 如果需要持续交付，你仅需要保证你的开发分支包含了全部代码就不会有问题（比如你为了在部署环境特化配置，但是配置没有同步给开发分支就会有问题，开发分支没有特化配置的提交，所以开发和线上不对等，不可以直接切） |
Select Language