V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
simonlu9
V2EX  ›  程序员

gitflow 在实践中的一些疑问

  •  
  •   simonlu9 · 2020-12-17 15:46:23 +08:00 · 2227 次点击
    这是一个创建于 1197 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 假设以下场景,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.我能想象开发遇到的情况都说了,不知道,我说的对不对,大家给点意见
    24 条回复    2020-12-22 09:37:38 +08:00
    boris93
        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 撇出去了
    chenluo0429
        2
    chenluo0429  
       2020-12-17 15:59:29 +08:00
    开发完提测的话先合并到 dev 。。。
    还没测的东西你就合并进 dev,这样跟直接在 dev 上开发有什么区别吗?
    你这个只能 revert b 功能的全部提交了,如果 a 跟 b 的代码有过冲突合并,那就很酸爽了。
    jerryzhou343
        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 ;
    jerryzhou343
        4
    jerryzhou343  
       2020-12-17 16:03:25 +08:00
    修正下命令:cherry-pick
    joesonw
        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 的拿过来
    wweir
        6
    wweir  
       2020-12-17 16:06:39 +08:00
    revert b
    既然是历史,还是保留下来吧
    KuroNekoFan
        7
    KuroNekoFan  
       2020-12-17 16:09:22 +08:00
    只把 feature a 合并到 master/发布分支呗
    不要告诉我改 bug 是直接在 dev 分支上操作的
    linxb
        8
    linxb  
       2020-12-17 16:23:33 +08:00
    但是如果 a 功能出现 bug,必须在 a 分支上修复,修复完之后再一次合并到 dev 分支,直到测试完成为止,上线就是把 a 分支合并到 release 发布。
    simonlu9
        9
    simonlu9  
    OP
       2020-12-17 16:34:42 +08:00
    @jerryzhou343 @KuroNekoFan 谢谢,那我理解错了,我以为开发完就可以合并到 dev,release,然后再 release 分支改 bug,像这样的话,一定要保证 feature 分支不能有其他分支的代码污染,还有一个问题,像这种多人开发的话,一般提测的话,像上面这种情况,是否要 ab 都合并到 dev 分支,然后在 dev 发版到测试,因为测试不可能单独测一个功能,如果混在一起,dev 肯定会污染
    beidounanxizi
        10
    beidounanxizi  
       2020-12-17 17:41:57 +08:00
    gitflow 看看美好 实践起来 还不如 都合并到 master git rebase 上
    lululau
        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 分支
    jerryzhou343
        12
    jerryzhou343  
       2020-12-17 20:00:40 +08:00
    @simonlu9 每个分支都有自己的角色(责任)和生命周期; dev 分支作为 feature 的汇聚分支,合并其他 feature 就是其责任,所以 dev 不存在污染一说; feature 有 bug,在对应 feature 修改,然后再合并到 dev ;如果有 bug 直接在 dev 修,那才是污染 dev 分支了,让 dev 承担了开发的职责;
    jerryzhou343
        13
    jerryzhou343  
       2020-12-17 20:07:49 +08:00
    @simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的;如果你们走的瀑布模式的流程;在 dev 分支修复 bug 是没问题的;如果你们走的敏捷迭代模式,最好不好在 dev 上修 bug ;因为在 sprint 中,某个 feature 可能赶不上时间点;所以建议的是不要在 dev 上修 bug ;不然 cherry-pick 有时候也挺麻烦的; feature 分支提交记录多用 rebase,这样可以让提交记录清晰,并且不会太多;
    hantsy
        14
    hantsy  
       2020-12-17 20:18:10 +08:00
    @boris93 这个比较适用。
    hantsy
        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 一下不是什么难事吧。
    simonlu9
        16
    simonlu9  
    OP
       2020-12-17 20:45:01 +08:00
    @hantsy 为什么合并到 dev,因为考虑到测试成本问题,因为公司问题,测试做不了这么完善,每一个 feature 都部署一个环境给测试,所以只能到合并到 dev 去,发版到测试环境。让测试统一测试,当然有 Bug 还是再 feature 修
    hantsy
        17
    hantsy  
       2020-12-17 21:09:42 +08:00
    @simonlu9

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

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

    我做过的有些项目,如果没有写测试(有些项目还有一定覆盖率的要求),直接认为没有完成。
    taogen
        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 。
    f6x
        19
    f6x  
       2020-12-17 21:16:11 +08:00
    重发一个新的 release, 只包含 A. (方法大家说了, cherry-pick dev 里的 A 提交)
    原 release 分支作废删除.

    gitflow 中,release 本就是个短生命期的临时分支.
    guyeu
        20
    guyeu  
       2020-12-18 11:44:23 +08:00   ❤️ 2
    所有的 feature 分支合并到主分支之前,都需要先合一下主分支处理完冲突,而不是在这个 merge 中合并,因此 feature 分支和主分支的交点只有一个简单的 merge,如果发现某个 feature 分支的内容有问题,那么 revert 这个 merge 就好了。revert 的复杂度取决于你们在该 merge 的基础上做的改动量。
    simonlu9
        21
    simonlu9  
    OP
       2020-12-19 21:15:35 +08:00
    @KuroNekoFan @beidounanxizi @boris93 @chenluo0429 @f6x @guyeu @hantsy @jerryzhou343 @joesonw @linxb
    @hantsy,我总结了,麻烦看看付加的信息,看看有没有什么问题
    hantsy
        22
    hantsy  
       2020-12-20 14:21:28 +08:00
    CI 是保证了在多人开发环境中如果有人代码 Break 了业务逻辑等,回归测试中立即报告问题。

    你这流程没法看,复杂的程序,国际化多人开发的项目参与过很多,没用过你这种复杂的 Git 流程。

    一句话,不写测试的 CI, CD 没太大意义。你这种加一个 CI,只是加快了相互扯皮的频率。
    f6x
        23
    f6x  
       2020-12-21 09:48:11 +08:00
    你补充的方法,完全和 gitflow 背道而驰了.

    没有正确的流程,只有适合的流程.
    看你这么重视 feature 隔离, 可以直接用 aoneflow 吧.
    jerryzhou343
        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 贸然合入,并不一定是好的选择)
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3640 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 84ms · UTC 10:44 · PVG 18:44 · LAX 03:44 · JFK 06:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.