这是一个创建于 1471 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 假设以下场景，A 和 B 都开发一个功能，各自从 dev 切一个 feature 出来开发，然后开发完提测的话先合并到 dev，然后就到 release 提测改 bug,但是现在有个问题，a 和 b 都差不多时间开发完，然后都合并到 dev 分支了，-。
- 这时候，a 的功能测试没问题，b 的测试有问题，这时候想只上 a 的功能，排除 b，但是 dev 已经包含了 a 和 b 的代码，这时候一般要怎么办？
第 1 条附言 · 2020-12-19 20:16:18 +08:00
谢谢大家回复，总结如下，不能完全用 gitflow 这个流程，我也看过 aoneflow 流程，也是有改良的，我觉得小型团队可以这样做
- 1 新功能开发还是要用 feature 开发，开发完并不能马上合并 dev,提测的话直接合并到 test 分支，多个 feature 就一起合并到 test，让测试验证，验证有 bug,然后自己再各自的 feature 修好，然后再合并到 test 分支（基于 master ），test 分支没问题直接上正式 en，正式没问题的话再把 feature 分支合并到 dev 和 master，保证 feature 是干净的，不参合任何代码，如果 a 和 b 到时候有谁上不了，直接用 master 分支拉一个副本出来然后合并到 feature 分支发版
- 2 .如果这时候正式环境有 Bug,而你又再 feature 上，按照 gitflow 流程到 master 拉个分支补丁处理，（这时候又个疑问，提测是否合到 test 分支上还是拉上一次的 release 分支）然后处理完在合并到 dev 和 mater
- 3.test 分支最好有一个自动检查，当 feature 分支 push 变更时，能够自动重新合并分支（ master+featrueA+featureB ）,部署就变得很简单
- 4.dev 分支好像变得没什么用
- 5. 还有一种情况就是，featureA 和 featureB 开发的时候，有一些公共代码要开发，这时候怎么办，因为 featureA 和 B 到要用到，我想到的时直接到 dev 提交这些公共的部分，然后 featureA，B 分别合并 dev 分支的公共代码，然后再把 dev 分支关上，不允许任何人提交，这样最保险
- 6.我能想象开发遇到的情况都说了，不知道，我说的对不对，大家给点意见
- 1 新功能开发还是要用 feature 开发，开发完并不能马上合并 dev,提测的话直接合并到 test 分支，多个 feature 就一起合并到 test，让测试验证，验证有 bug,然后自己再各自的 feature 修好，然后再合并到 test 分支（基于 master ），test 分支没问题直接上正式 en，正式没问题的话再把 feature 分支合并到 dev 和 master，保证 feature 是干净的，不参合任何代码，如果 a 和 b 到时候有谁上不了，直接用 master 分支拉一个副本出来然后合并到 feature 分支发版
- 2 .如果这时候正式环境有 Bug,而你又再 feature 上，按照 gitflow 流程到 master 拉个分支补丁处理，（这时候又个疑问，提测是否合到 test 分支上还是拉上一次的 release 分支）然后处理完在合并到 dev 和 mater
- 3.test 分支最好有一个自动检查，当 feature 分支 push 变更时，能够自动重新合并分支（ master+featrueA+featureB ）,部署就变得很简单
- 4.dev 分支好像变得没什么用
- 5. 还有一种情况就是，featureA 和 featureB 开发的时候，有一些公共代码要开发，这时候怎么办，因为 featureA 和 B 到要用到，我想到的时直接到 dev 提交这些公共的部分，然后 featureA，B 分别合并 dev 分支的公共代码，然后再把 dev 分支关上，不允许任何人提交，这样最保险
- 6.我能想象开发遇到的情况都说了，不知道，我说的对不对，大家给点意见
 |
1
boris93 2020-12-17 15:58:29 +08:00 via Android
我司是 feature 直接合到 master，CI/CD 检测到 master 有更新就自动部署到 dev 环境，并打 git tag
生产部署取 git tag 对应的代码版本 对于你这种情况，我们会选择都不上线，等 bug 修好再一起上。很紧急的上线的话，那么就先把 b 的代码改回去，这就相当于只上线了 a 。 话说你们应该也有个 release 用的分支吧，把 a 相关的提交 cherry-pick 到 release 用的分支，就可以把 b 撇出去了 |
 |
2
chenluo0429 2020-12-17 15:59:29 +08:00
开发完提测的话先合并到 dev 。。。
还没测的东西你就合并进 dev，这样跟直接在 dev 上开发有什么区别吗？ 你这个只能 revert b 功能的全部提交了，如果 a 跟 b 的代码有过冲突合并，那就很酸爽了。 |
 |
3
jerryzhou343 2020-12-17 16:02:06 +08:00  1
1. a,b 在各自分支修的 bug ；那么丢弃 dev，重新基于上一次 release 拉一个 dev，然后将 a 合并到新的 dev ；
2. a,b 在修 bug 的时候是在 dev 修的。通过 pick-cherry 将 a 的提交挑出来合并到 a，然后基于上一次 release 重新拉一个 dev，将 a 合并到新的 dev ； |
|
4
jerryzhou343 2020-12-17 16:03:25 +08:00
修正下命令:cherry-pick
|
 |
5
joesonw 2020-12-17 16:04:41 +08:00 1
git checkout $COMMIT_HASH$
git branch release-XXX git cherry-pick 先回到没有 a,b 的时候, 然后把 a 的拿过来 |
 |
6
wweir 2020-12-17 16:06:39 +08:00
revert b
既然是历史，还是保留下来吧 |
 |
7
KuroNekoFan 2020-12-17 16:09:22 +08:00
只把 feature a 合并到 master/发布分支呗
不要告诉我改 bug 是直接在 dev 分支上操作的 |
 |
8
linxb 2020-12-17 16:23:33 +08:00
但是如果 a 功能出现 bug，必须在 a 分支上修复，修复完之后再一次合并到 dev 分支，直到测试完成为止，上线就是把 a 分支合并到 release 发布。
|
 |
9
simonlu9 OP @jerryzhou343 @KuroNekoFan 谢谢，那我理解错了，我以为开发完就可以合并到 dev,release,然后再 release 分支改 bug,像这样的话，一定要保证 feature 分支不能有其他分支的代码污染，还有一个问题，像这种多人开发的话，一般提测的话，像上面这种情况，是否要 ab 都合并到 dev 分支，然后在 dev 发版到测试，因为测试不可能单独测一个功能，如果混在一起，dev 肯定会污染
|
 |
10
beidounanxizi 2020-12-17 17:41:57 +08:00
gitflow 看看美好 实践起来 还不如 都合并到 master git rebase 上
|
 |
11
lululau 2020-12-17 18:03:02 +08:00
我和楼主对 gitflow 的理解是一致的，代码是在测试之前 merge 到 develop 的；对于 A 先于 B merge 到 develop, 而 A 由于进度问题需要比 B 晚发布的情况，gitflow 确实没有说明这种情况该怎么处理，小项目可以 cherrypick，项目大了的话都 cherrypick 的话容易出岔子；所以我们没有用 gitflow，对于开发周期大于一个标准发布周期的在独立的分支上开发和测试，对于小周期的可以直接在 develop 上，测试过了到 master，最后用 master 发布，没有用 release 分支
|
|
12
jerryzhou343 2020-12-17 20:00:40 +08:00
@simonlu9 每个分支都有自己的角色（责任）和生命周期； dev 分支作为 feature 的汇聚分支，合并其他 feature 就是其责任，所以 dev 不存在污染一说； feature 有 bug，在对应 feature 修改，然后再合并到 dev ；如果有 bug 直接在 dev 修，那才是污染 dev 分支了，让 dev 承担了开发的职责；
|
|
13
jerryzhou343 2020-12-17 20:07:49 +08:00
@simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的；如果你们走的瀑布模式的流程；在 dev 分支修复 bug 是没问题的；如果你们走的敏捷迭代模式，最好不好在 dev 上修 bug ；因为在 sprint 中，某个 feature 可能赶不上时间点；所以建议的是不要在 dev 上修 bug ；不然 cherry-pick 有时候也挺麻烦的； feature 分支提交记录多用 rebase，这样可以让提交记录清晰，并且不会太多；
|
 |
15
hantsy 2020-12-17 20:27:00 +08:00
基本上一个严格执行 Github Flow 还是 GitFlow 都是不会有大问题。
1 。 如果小团队，没有专人去维护 Github 合并，可以用最精简的 Github Flow 就行了，CI 执行严格的测试（单元测试，集成测试等），合并时直接部署到生产环境。 2 。B 提交的功能测试有问题，难道是不是先在 CI 跑测试出来的吗? 测试都没有 Pass，为什么会合并到 Dev 。我是觉得楼主这问题有点莫名其妙。 3 。 即使 B 提交的东西不想要了，想回之前的某个版本，reset 一下不是什么难事吧。 |
|
16
simonlu9 OP @hantsy 为什么合并到 dev,因为考虑到测试成本问题，因为公司问题，测试做不了这么完善，每一个 feature 都部署一个环境给测试，所以只能到合并到 dev 去，发版到测试环境。让测试统一测试，当然有 Bug 还是再 feature 修
|
|
17
hantsy 2020-12-17 21:09:42 +08:00
@simonlu9
写测试习惯在于项目开始阶段的积累，需要一部分时间。通常，项目启动阶段，我们需要花一点时间，去跑通整个开发到测试，CI，CD 全部过程的各个环节，这个时期也是开发人员及其他磨合的最好时期。到后面项目复杂后也一路畅通，后面再使用人力测试（ exploring test ）的成本会远远大于写测试的成本。如果你的项目持续 6-12 个月，人力测试的成本应该会高出一个数量级以上。 当然国内一致认为早期做那些都是在浪费时间，习惯早早出个 UI，什么狗屁远景规划，拿去忽悠老板或者客户，后面花多少时间去扯皮谁也管不了。 我做过的有些项目，如果没有写测试（有些项目还有一定覆盖率的要求），直接认为没有完成。 |
 |
18
taogen 2020-12-17 21:13:06 +08:00 via Android 1
可以在加一个预发布分支 pre-release，该分支所有代码都是测试通过的。dev 分支则作为代码汇总测试分支。
大致流程： 1. 所有 feat → dev，准备测试。 2. feat-1 测试通过，feat-1 → pre-release 。 3. feat-1 测试不通过，修改 feat-1 后，feat-1 → dev，继续测试。 4. 发布所有 feat，pre-release → release 。 |
 |
19
f6x 2020-12-17 21:16:11 +08:00
重发一个新的 release, 只包含 A. (方法大家说了, cherry-pick dev 里的 A 提交)
原 release 分支作废删除. gitflow 中,release 本就是个短生命期的临时分支. |
 |
20
guyeu 2020-12-18 11:44:23 +08:00 2
所有的 feature 分支合并到主分支之前，都需要先合一下主分支处理完冲突，而不是在这个 merge 中合并，因此 feature 分支和主分支的交点只有一个简单的 merge，如果发现某个 feature 分支的内容有问题，那么 revert 这个 merge 就好了。revert 的复杂度取决于你们在该 merge 的基础上做的改动量。
|
|
21
simonlu9 OP @KuroNekoFan @beidounanxizi @boris93 @chenluo0429 @f6x @guyeu @hantsy @jerryzhou343 @joesonw @linxb
@hantsy，我总结了，麻烦看看付加的信息，看看有没有什么问题 |
|
22
hantsy 2020-12-20 14:21:28 +08:00
CI 是保证了在多人开发环境中如果有人代码 Break 了业务逻辑等，回归测试中立即报告问题。
你这流程没法看，复杂的程序，国际化多人开发的项目参与过很多，没用过你这种复杂的 Git 流程。 一句话，不写测试的 CI, CD 没太大意义。你这种加一个 CI，只是加快了相互扯皮的频率。 |
|
23
f6x 2020-12-21 09:48:11 +08:00
你补充的方法,完全和 gitflow 背道而驰了.
没有正确的流程,只有适合的流程. 看你这么重视 feature 隔离, 可以直接用 aoneflow 吧. |
|
24
jerryzhou343 2020-12-22 09:37:38 +08:00 2
@simonlu9 每个分支都有自己的角色（责任）和生命周期，所以不用纠结你的流程一定要遵循 gitflow，你可以定义自己的 xxx 流程；
回复第一点：这个描述下，这个流程中有 feature , release, test, master，dev ; 在这个模式下，如果团队对提交干净整洁度没有洁癖的话，test，dev 分支就没啥用了。到测试时间点的时候，拉 release，然后合并测试，测试 ok 直接上 release ；如果你们有提交整洁度要求，那可以用 test-xxx 这样的分支来做初次汇聚，测试完成； feature 提交做 rebase，然后再拉 release 合并发布； 回复第二点：基于上一次发布拉出 fix-xxx 分支，修复完成；看发布计划，如果是紧急重要，这个 bug fix 提前单独 release 出去；如果不紧急重要，就跟着发布计划，合并到 test 测试，跟着需求上线； 回复第三点：feature 分支的内容并不一定需要马上合并到 test 的，也许只是开发人员同步代码的时候一次提交，并不想合并，所以这里不建议做自动化； 回复第四点： 分支存在的理由是它有自己的角色和职责；先有需求，才有了对应的分支，不要陷入固定的思维，可以问下自己，gitflow 为什么有 dev 分支； 回复第五点：公共部分代码是不是可以认为是 featureC 呢；如果没有公共部分，featureA，featureB 就无法进行下去；那么可以先做好公共部分再启动 featureA，featureB 的开发；或者三个分支独立，featureA，featureB 先依赖一个接口，然后在测试的是汇聚；或者 featureA,featureB 合并为一个需求,一起开发；（公共部分代码在这个情况下也是不稳定的，featureA,featureB 贸然合入，并不一定是好的选择) |
Select Language