这是一个创建于 1803 天前的主题，其中的信息可能已经有所发展或是发生改变。
按照 gitflow 的流程，开发时有 Develop Release Master 三个主要分支，
普通的 gitflow 开发流程就是：
- 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
- 新功能开发完成后 feature 合并入 Develop 分支
- 然后 Develop 合并入 Release 分支
- 最后确认无误后 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 区别会越来越大。
这个问题相信大家开发时一定都有遇到过，不知道大家是怎么解决这个问题的？
 |
1
tt67wq 2020-01-21 19:05:47 +08:00
1. 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
2. 新功能开发完成后 feature 合并入 Develop 分支，测试环境测试 3. 然后 feature 合并入 Release 分支， 预发测试 4. 最后确认无误后 Release 合并入 Master 分支正式发布到生产环境 难道不是这个流程，怎么会有把测试分支合并进 release 的哟 |
 |
2
wellsc 2020-01-21 19:11:52 +08:00
我们是能用 rebase 合并就尽量不用 merge 合并，能 fork 仓库开发功能，就尽量不会开 feature 分支。子仓库开发完成之后触发 ci 通过之后再 pr 到 主仓库版本分支，版本分支合并之后进 develop 测试，develop 测试完成之后进 prerelease， 再之后进 master
|
 |
3
ispinfx 2020-01-21 19:39:09 +08:00 via iPhone
不发布为啥急着合并到 dev ？
|
 |
4
mcfog 2020-01-21 19:46:02 +08:00 via Android  1
- 确定要发的再合并
- 如果就是确定不确定发不发，但就是要测 /合并，那么就在 feature 分支开发的时候就带上 feature switch，测试的时候同时测 feature on/off 的情况 - feature 相关 bugfix 不进 dev 而是进各自 feature 再重新合并 - 需要加急单独发布某个 feature 时从 prod 拉 release-urgent 合入 feature 后测试发布，然后再把 release-urgent 并入 release 后移除 - 即使要测也不合并 dev，而是每次由 ci 过程来 merge （不推送 vcs ） 大概就是以上几种措施的排列组合 |
 |
5
wangyzj 2020-01-21 22:32:22 +08:00
你说的情况貌似叫 hotfix 了吧
|
 |
6
gouflv 2020-01-21 22:54:22 +08:00 via iPhone
你可能需要一个迭代分支，feature 合并到 dev 测试完后，再将 feature 合并到迭代分支，迭代整个完成的时候，将迭代分支合并到 master。
|
 |
7
xcstream 2020-01-22 03:31:32 +08:00
加个开关，代码和用不用这个功能分开
|
 |
8
xxapp 2020-01-22 08:15:09 +08:00 via Android
cherry pick
|
 |
9
hakono OP @tt67wq 因为说的是 gitflow 啊，所有讲解 git flow 的都是 Dev -> Release -> master 的合并流程，feature 生于 Dev 最终也是合并回 Dev
|
 |
10
avenger 2020-01-22 08:37:49 +08:00 via iPhone
我们一开始用 gitflow，现在换成 github flow 了
|
 |
11
dbskcnc 2020-01-22 09:49:58 +08:00
feature flags 了解下
https://medium.com/@tmaslen/getting-started-with-feature-flags-fc3e617260fe gitlab 用得很多,各种新功能都先放在 flags 中，https://docs.gitlab.com/ee/development/feature_flags/ |
 |
12
KuroNekoFan 2020-01-22 09:56:41 +08:00
还是 github flow 好
|
 |
13
rioshikelong121 2020-01-22 10:05:04 +08:00
测试完成以后，从 feature 分支直接合并到 release ？
|
 |
14
MinonHeart 2020-01-22 10:39:19 +08:00
觉得这是版本规划的问题。我们是 feature 完成后不会进入 develop，只有确定要测试并上线才会进入 develop。
gitflow 流程是一楼说的那种。不过我们为了配合 ci，分支合并后就删除，我们用的和楼主的方式相似，属于 gitflow 的变种。 另外，你不上线的 feature 测试后，待要上线时不需要重新测吗（比如合并有冲突的情况）？浪费测试资源 |
|
15
MinonHeart 2020-01-22 10:44:00 +08:00
按照我们的方式，master 和线上同步，develop 最多到下个版本的内容，下下个版本的 feature 都是处于 pending 状态
|
 |
16
hantsy 2020-01-22 11:01:53 +08:00
Git Flow 应该还要包括 hotfix, 适合多个版本维护开发。
一般项目用 Github Flow 简单些。 |
|
17
hakono OP |
 |
18
angel001ma 2020-01-22 12:20:56 +08:00
dev 是测试环境，feature/xxx 上线合到 release
有新功能需要开发的话，就在 master 上新建 feature/xxx 分支进行开发 |
 |
19
kassadin 2020-01-23 04:37:07 +08:00 1
git flow/github flow 之类的主要是对外线性单版本的情况，发布的也都是最近何如 feature
你的问题是 release 时才确定 feature，所以这个模型不适用很正常，不用生搬硬套 细节操作还按这个来，把 feature 当 dev 用就可以了，release 时选 feature，发布后合回 dev， 其他 feature merge dev 即可。 |
 |
20
networm 2020-02-05 11:13:01 +08:00 1
这个问题其实与分支没多大关系，建议阅读以下两本书：
持续集成 (豆瓣) https://book.douban.com/subject/10769596/ 持续交付 (豆瓣) https://book.douban.com/subject/6862062/ |
Select Language