gitflow 在实践中的一些疑问

[simonlu9]

• 假设以下场景，A 和 B 都开发一个功能，各自从 dev 切一个 feature 出来开发，然后开发完提测的话先合并到 dev，然后就到 release 提测改 bug,但是现在有个问题，a 和 b 都差不多时间开发完，然后都合并到 dev 分支了，-。
• 这时候，a 的功能测试没问题，b 的测试有问题，这时候想只上 a 的功能，排除 b，但是 dev 已经包含了 a 和 b 的代码，这时候一般要怎么办？

[boris93]

我司是 feature 直接合到 master，CI/CD 检测到 master 有更新就自动部署到 dev 环境，并打 git tag
生产部署取 git tag 对应的代码版本

对于你这种情况，我们会选择都不上线，等 bug 修好再一起上。很紧急的上线的话，那么就先把 b 的代码改回去，这就相当于只上线了 a 。

话说你们应该也有个 release 用的分支吧，把 a 相关的提交 cherry-pick 到 release 用的分支，就可以把 b 撇出去了

[chenluo0429]

开发完提测的话先合并到 dev 。。。
还没测的东西你就合并进 dev，这样跟直接在 dev 上开发有什么区别吗？
你这个只能 revert b 功能的全部提交了，如果 a 跟 b 的代码有过冲突合并，那就很酸爽了。

[jerryzhou343]

1. a,b 在各自分支修的 bug ；那么丢弃 dev，重新基于上一次 release 拉一个 dev，然后将 a 合并到新的 dev ；
2. a,b 在修 bug 的时候是在 dev 修的。通过 pick-cherry 将 a 的提交挑出来合并到 a，然后基于上一次 release 重新拉一个 dev，将 a 合并到新的 dev ；

[jerryzhou343]

修正下命令:cherry-pick

[joesonw]

git checkout $COMMIT_HASH$
git branch release-XXX
git cherry-pick

先回到没有 a,b 的时候, 然后把 a 的拿过来

[wweir]

revert b
既然是历史，还是保留下来吧

[KuroNekoFan]

只把 feature a 合并到 master/发布分支呗
不要告诉我改 bug 是直接在 dev 分支上操作的

[linxb]

但是如果 a 功能出现 bug，必须在 a 分支上修复，修复完之后再一次合并到 dev 分支，直到测试完成为止，上线就是把 a 分支合并到 release 发布。

[simonlu9]

@jerryzhou343 @KuroNekoFan 谢谢，那我理解错了，我以为开发完就可以合并到 dev,release,然后再 release 分支改 bug,像这样的话，一定要保证 feature 分支不能有其他分支的代码污染，还有一个问题，像这种多人开发的话，一般提测的话，像上面这种情况，是否要 ab 都合并到 dev 分支，然后在 dev 发版到测试，因为测试不可能单独测一个功能，如果混在一起，dev 肯定会污染

[beidounanxizi]

gitflow 看看美好 实践起来 还不如 都合并到 master git rebase 上

[lululau]

我和楼主对 gitflow 的理解是一致的，代码是在测试之前 merge 到 develop 的；对于 A 先于 B merge 到 develop, 而 A 由于进度问题需要比 B 晚发布的情况，gitflow 确实没有说明这种情况该怎么处理，小项目可以 cherrypick，项目大了的话都 cherrypick 的话容易出岔子；所以我们没有用 gitflow，对于开发周期大于一个标准发布周期的在独立的分支上开发和测试，对于小周期的可以直接在 develop 上，测试过了到 master，最后用 master 发布，没有用 release 分支

[jerryzhou343]

@simonlu9 每个分支都有自己的角色（责任）和生命周期； dev 分支作为 feature 的汇聚分支，合并其他 feature 就是其责任，所以 dev 不存在污染一说； feature 有 bug，在对应 feature 修改，然后再合并到 dev ；如果有 bug 直接在 dev 修，那才是污染 dev 分支了，让 dev 承担了开发的职责；

[jerryzhou343]

@simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的；如果你们走的瀑布模式的流程；在 dev 分支修复 bug 是没问题的；如果你们走的敏捷迭代模式，最好不好在 dev 上修 bug ；因为在 sprint 中，某个 feature 可能赶不上时间点；所以建议的是不要在 dev 上修 bug ；不然 cherry-pick 有时候也挺麻烦的； feature 分支提交记录多用 rebase，这样可以让提交记录清晰，并且不会太多；

[hantsy]

@boris93 这个比较适用。

[hantsy]

基本上一个严格执行 Github Flow 还是 GitFlow 都是不会有大问题。

1 。 如果小团队，没有专人去维护 Github 合并，可以用最精简的 Github Flow 就行了，CI 执行严格的测试（单元测试，集成测试等），合并时直接部署到生产环境。

2 。B 提交的功能测试有问题，难道是不是先在 CI 跑测试出来的吗? 测试都没有 Pass，为什么会合并到 Dev 。我是觉得楼主这问题有点莫名其妙。

3 。 即使 B 提交的东西不想要了，想回之前的某个版本，reset 一下不是什么难事吧。

[simonlu9]

@hantsy 为什么合并到 dev,因为考虑到测试成本问题，因为公司问题，测试做不了这么完善，每一个 feature 都部署一个环境给测试，所以只能到合并到 dev 去，发版到测试环境。让测试统一测试，当然有 Bug 还是再 feature 修

[hantsy]

@simonlu9

写测试习惯在于项目开始阶段的积累，需要一部分时间。通常，项目启动阶段，我们需要花一点时间，去跑通整个开发到测试，CI，CD 全部过程的各个环节，这个时期也是开发人员及其他磨合的最好时期。到后面项目复杂后也一路畅通，后面再使用人力测试（ exploring test ）的成本会远远大于写测试的成本。如果你的项目持续 6-12 个月，人力测试的成本应该会高出一个数量级以上。

当然国内一致认为早期做那些都是在浪费时间，习惯早早出个 UI，什么狗屁远景规划，拿去忽悠老板或者客户，后面花多少时间去扯皮谁也管不了。

我做过的有些项目，如果没有写测试（有些项目还有一定覆盖率的要求），直接认为没有完成。

[taogen]

可以在加一个预发布分支 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 。

[f6x]

重发一个新的 release, 只包含 A. (方法大家说了, cherry-pick dev 里的 A 提交)
原 release 分支作废删除.

gitflow 中,release 本就是个短生命期的临时分支.

[guyeu]

所有的 feature 分支合并到主分支之前，都需要先合一下主分支处理完冲突，而不是在这个 merge 中合并，因此 feature 分支和主分支的交点只有一个简单的 merge，如果发现某个 feature 分支的内容有问题，那么 revert 这个 merge 就好了。revert 的复杂度取决于你们在该 merge 的基础上做的改动量。