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

gitflow 在实践中的一些疑问

  •  
  •   simonlu9 · 351 天前 · 1525 次点击
    这是一个创建于 351 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 假设以下场景,A 和 B 都开发一个功能,各自从 dev 切一个 feature 出来开发,然后开发完提测的话先合并到 dev,然后就到 release 提测改 bug,但是现在有个问题,a 和 b 都差不多时间开发完,然后都合并到 dev 分支了,-。
    • 这时候,a 的功能测试没问题,b 的测试有问题,这时候想只上 a 的功能,排除 b,但是 dev 已经包含了 a 和 b 的代码,这时候一般要怎么办?
    第 1 条附言  ·  349 天前
    谢谢大家回复,总结如下,不能完全用 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  
       351 天前 via Android
    我司是 feature 直接合到 master,CI/CD 检测到 master 有更新就自动部署到 dev 环境,并打 git tag
    生产部署取 git tag 对应的代码版本

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

    话说你们应该也有个 release 用的分支吧,把 a 相关的提交 cherry-pick 到 release 用的分支,就可以把 b 撇出去了
    chenluo0429
        2
    chenluo0429  
       351 天前
    开发完提测的话先合并到 dev 。。。
    还没测的东西你就合并进 dev,这样跟直接在 dev 上开发有什么区别吗?
    你这个只能 revert b 功能的全部提交了,如果 a 跟 b 的代码有过冲突合并,那就很酸爽了。
    jerryzhou343
        3
    jerryzhou343  
       351 天前   ❤️ 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  
       351 天前
    修正下命令:cherry-pick
    joesonw
        5
    joesonw  
       351 天前   ❤️ 1
    git checkout $COMMIT_HASH$
    git branch release-XXX
    git cherry-pick

    先回到没有 a,b 的时候, 然后把 a 的拿过来
    wweir
        6
    wweir  
       351 天前
    revert b
    既然是历史,还是保留下来吧
    KuroNekoFan
        7
    KuroNekoFan  
       351 天前
    只把 feature a 合并到 master/发布分支呗
    不要告诉我改 bug 是直接在 dev 分支上操作的
    linxb
        8
    linxb  
       351 天前
    但是如果 a 功能出现 bug,必须在 a 分支上修复,修复完之后再一次合并到 dev 分支,直到测试完成为止,上线就是把 a 分支合并到 release 发布。
    simonlu9
        9
    simonlu9  
    OP
       351 天前
    @jerryzhou343 @KuroNekoFan 谢谢,那我理解错了,我以为开发完就可以合并到 dev,release,然后再 release 分支改 bug,像这样的话,一定要保证 feature 分支不能有其他分支的代码污染,还有一个问题,像这种多人开发的话,一般提测的话,像上面这种情况,是否要 ab 都合并到 dev 分支,然后在 dev 发版到测试,因为测试不可能单独测一个功能,如果混在一起,dev 肯定会污染
    beidounanxizi
        10
    beidounanxizi  
       351 天前
    gitflow 看看美好 实践起来 还不如 都合并到 master git rebase 上
    lululau
        11
    lululau  
       351 天前
    我和楼主对 gitflow 的理解是一致的,代码是在测试之前 merge 到 develop 的;对于 A 先于 B merge 到 develop, 而 A 由于进度问题需要比 B 晚发布的情况,gitflow 确实没有说明这种情况该怎么处理,小项目可以 cherrypick,项目大了的话都 cherrypick 的话容易出岔子;所以我们没有用 gitflow,对于开发周期大于一个标准发布周期的在独立的分支上开发和测试,对于小周期的可以直接在 develop 上,测试过了到 master,最后用 master 发布,没有用 release 分支
    jerryzhou343
        12
    jerryzhou343  
       351 天前
    @simonlu9 每个分支都有自己的角色(责任)和生命周期; dev 分支作为 feature 的汇聚分支,合并其他 feature 就是其责任,所以 dev 不存在污染一说; feature 有 bug,在对应 feature 修改,然后再合并到 dev ;如果有 bug 直接在 dev 修,那才是污染 dev 分支了,让 dev 承担了开发的职责;
    jerryzhou343
        13
    jerryzhou343  
       351 天前
    @simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的;如果你们走的瀑布模式的流程;在 dev 分支修复 bug 是没问题的;如果你们走的敏捷迭代模式,最好不好在 dev 上修 bug ;因为在 sprint 中,某个 feature 可能赶不上时间点;所以建议的是不要在 dev 上修 bug ;不然 cherry-pick 有时候也挺麻烦的; feature 分支提交记录多用 rebase,这样可以让提交记录清晰,并且不会太多;
    hantsy
        14
    hantsy  
       351 天前
    @boris93 这个比较适用。
    hantsy
        15
    hantsy  
       351 天前
    基本上一个严格执行 Github Flow 还是 GitFlow 都是不会有大问题。

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

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

    3 。 即使 B 提交的东西不想要了,想回之前的某个版本,reset 一下不是什么难事吧。
    simonlu9
        16
    simonlu9  
    OP
       351 天前
    @hantsy 为什么合并到 dev,因为考虑到测试成本问题,因为公司问题,测试做不了这么完善,每一个 feature 都部署一个环境给测试,所以只能到合并到 dev 去,发版到测试环境。让测试统一测试,当然有 Bug 还是再 feature 修
    hantsy
        17
    hantsy  
       351 天前
    @simonlu9

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

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

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

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

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

    一句话,不写测试的 CI, CD 没太大意义。你这种加一个 CI,只是加快了相互扯皮的频率。
    f6x
        23
    f6x  
       348 天前
    你补充的方法,完全和 gitflow 背道而驰了.

    没有正确的流程,只有适合的流程.
    看你这么重视 feature 隔离, 可以直接用 aoneflow 吧.
    jerryzhou343
        24
    jerryzhou343  
       347 天前   ❤️ 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   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2338 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 07:24 · PVG 15:24 · LAX 23:24 · JFK 02:24
    ♥ Do have faith in what you're doing.