gitflow 在开发中的一个疑惑

[hakono]

按照 gitflow 的流程，开发时有 Develop Release Master 三个主要分支，

普通的 gitflow 开发流程就是：

1. 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
2. 新功能开发完成后 feature 合并入 Develop 分支
3. 然后 Develop 合并入 Release 分支
4. 最后确认无误后 Release 合并入 Master 分支正式发布到生产环境

但是最近在使用这套流程的时候遇到了个非常大的问题，而所有讲解 gitflow 的文章都似乎特意避开了这个问题不谈，明明是实际开发的话一定会遇到的问题，所以来问问大家怎么解决

问题：

同时有两个新功能需要开发，我们就叫 feature/01 feautre/02 吧

两个功能开发完毕，先后合并入了 Develop 进行线上 dev 环境的测试。

那么然后问题就来了，如果只想发布功能 feature/02 到生产换件的话，我该怎么做？

现在 Develop 分支上已经合并入了 feature/01 和 feature/02，如果按照 gitflow 的做法，把 Develop 分支合并入 Release 分支的话， 那么 feautre/01 的变更也会同时被合并

当然，一个解决办法就是不按照 gitflow 的做法，不把 Develop 分支合并入 Release 分支，而是直接把 feature/02 分支合并到 Release 分支上。但是这么做的话，只有两个 feature 分支还好，如果同时开发的 feature 分支非常多的话，每次发布功能都是直接 feature 分支合并入 Release 分支，那么 Development 分支的还有什么意义，以及这么做同时还能预见到，Develop 分支和 Release 区别会越来越大。

这个问题相信大家开发时一定都有遇到过，不知道大家是怎么解决这个问题的？

[tt67wq]

1. 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
2. 新功能开发完成后 feature 合并入 Develop 分支，测试环境测试
3. 然后 feature 合并入 Release 分支， 预发测试
4. 最后确认无误后 Release 合并入 Master 分支正式发布到生产环境

难道不是这个流程，怎么会有把测试分支合并进 release 的哟

[wellsc]

我们是能用 rebase 合并就尽量不用 merge 合并，能 fork 仓库开发功能，就尽量不会开 feature 分支。子仓库开发完成之后触发 ci 通过之后再 pr 到 主仓库版本分支，版本分支合并之后进 develop 测试，develop 测试完成之后进 prerelease， 再之后进 master

[ispinfx]

不发布为啥急着合并到 dev ？

[mcfog]

- 确定要发的再合并
- 如果就是确定不确定发不发，但就是要测 /合并，那么就在 feature 分支开发的时候就带上 feature switch，测试的时候同时测 feature on/off 的情况
- feature 相关 bugfix 不进 dev 而是进各自 feature 再重新合并
- 需要加急单独发布某个 feature 时从 prod 拉 release-urgent 合入 feature 后测试发布，然后再把 release-urgent 并入 release 后移除
- 即使要测也不合并 dev，而是每次由 ci 过程来 merge （不推送 vcs ）

大概就是以上几种措施的排列组合

[wangyzj]

你说的情况貌似叫 hotfix 了吧

[gouflv]

你可能需要一个迭代分支，feature 合并到 dev 测试完后，再将 feature 合并到迭代分支，迭代整个完成的时候，将迭代分支合并到 master。

[xcstream]

加个开关，代码和用不用这个功能分开

[xxapp]

cherry pick

[hakono]

@tt67wq 因为说的是 gitflow 啊，所有讲解 git flow 的都是 Dev -> Release -> master 的合并流程，feature 生于 Dev 最终也是合并回 Dev

[avenger]

我们一开始用 gitflow，现在换成 github flow 了

[dbskcnc]

feature flags 了解下

https://medium.com/@tmaslen/getting-started-with-feature-flags-fc3e617260fe

gitlab 用得很多,各种新功能都先放在 flags 中，https://docs.gitlab.com/ee/development/feature_flags/

[KuroNekoFan]

还是 github flow 好

[rioshikelong121]

测试完成以后，从 feature 分支直接合并到 release ？

[MinonHeart]

觉得这是版本规划的问题。我们是 feature 完成后不会进入 develop，只有确定要测试并上线才会进入 develop。

gitflow 流程是一楼说的那种。不过我们为了配合 ci，分支合并后就删除，我们用的和楼主的方式相似，属于 gitflow 的变种。

另外，你不上线的 feature 测试后，待要上线时不需要重新测吗（比如合并有冲突的情况）？浪费测试资源

[MinonHeart]

按照我们的方式，master 和线上同步，develop 最多到下个版本的内容，下下个版本的 feature 都是处于 pending 状态

[hantsy]

Git Flow 应该还要包括 hotfix, 适合多个版本维护开发。

一般项目用 Github Flow 简单些。

[hakono]

@ispinfx
@mcfog
感谢回复，虽说之后我也觉得解决这个问题的一个最简单方法就是不发布的 feature 就不合并到 Dev
但也架不住总有几个 feature 是客户要求先开发出来放到 Dev 环境上，给他们先用着，然后根据情况选择再决定先后发布到生产环境里

[angel001ma]

dev 是测试环境，feature/xxx 上线合到 release
有新功能需要开发的话，就在 master 上新建 feature/xxx 分支进行开发

[kassadin]

git flow/github flow 之类的主要是对外线性单版本的情况，发布的也都是最近何如 feature

你的问题是 release 时才确定 feature，所以这个模型不适用很正常，不用生搬硬套

细节操作还按这个来，把 feature 当 dev 用就可以了，release 时选 feature，发布后合回 dev， 其他 feature merge dev 即可。

[networm]

这个问题其实与分支没多大关系，建议阅读以下两本书：

持续集成 (豆瓣)
https://book.douban.com/subject/10769596/

持续交付 (豆瓣)
https://book.douban.com/subject/6862062/