大家 git 分支流程是怎么样的？

[DingDingDang123]

主分支 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

[hlwjia]

https://riggaroo.dev/using-git-flow-for-android-development/

[yl20181003]

git-flow

[gzf6]

Trunk base

[CasualYours]

你的这两种方案都有一些问题。

两个方案都没有版本的概念，这样会导致你本次功能上线出现问题后，无法正确回滚至上一版本。方案二不应该在测试后再进行代码合并，测试的永远应该是最后要上线的代码。

我公司通常这么处理的：

- 从 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 去重复上面的过程

[caixiangyu17]

其实 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 ，然后还得别人问找提交的人，为啥编译不过了，测试挂了之类的问题

[xz410236056]

@hlwjia #1 拿 2015 年的东西说举例子。。。
@yl20181003 #2
@gzf6 #3

git flow 发明人 Vincent 都说 git flow 不适合持续交付了。。

[MXuD0ng]

你这两个方式都是按照人来划分分支的，我觉得可以考虑这样：
如果是大型 feature 要切成小的 feature ，
然后一个 feature 一个分支，两个人开发完了小 feature 就合到开发分支（目的是始终保持开发分支拥有全部代码），
最后测试直接从开发分支切除测试分支（我不太理解为什么要 merge 到测试分支），然后测试通过后封版，推上线。

如果需要持续交付，你仅需要保证你的开发分支包含了全部代码就不会有问题（比如你为了在部署环境特化配置，但是配置没有同步给开发分支就会有问题，开发分支没有特化配置的提交，所以开发和线上不对等，不可以直接切）