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

请教一个 git 分支管理的问题。

  •  
  •   firhome · 2019-08-08 09:40:31 +08:00 · 3099 次点击
    这是一个创建于 1695 天前的主题,其中的信息可能已经有所发展或是发生改变。
    生产环境--> master

    测试环境--> test


    现在我们每次开发都是从 test 上 拉分支 branch-a, branch-b, branch-c .....

    开发完毕以后 合到 test 分支 一次迭代可能有多个 branch。

    [然后测试若有 bug 就直接在 test 环境更改了]

    测试完毕 test 合进 master。

    现在的问题是,已经合进 test,突然某个 branch 在 test 环境测试不通过,或者不上线。 请问这个时候怎么办呢?

    比如:branch-a , branch-b ,branch-c 依次合进 test, 其中 branch-b 暂时不要了。


    另外,合进 test 的分支若要改 bug,应该还是在原来分支改,改完再合进 test,应该是这样才对吧?
    第 1 条附言  ·  2019-08-09 10:03:51 +08:00
    感谢各位的回复,可能我没把我们现在的状态说清楚。。git flow 我昨天也看了一下。

    有点不理解抽象出来的 release 分支的作用。。


    我们现在的分支

    master ---> 对应 www.abc.com
    (发布的时候服务器上的 git,通过 ci 脚本 自动拉取 master 分支内容编译,Nginx 映射到 dist 目录)

    test ---> 对应 test.abc.com
    (发布的时候服务器上的 git,通过 ci 脚本 自动拉取 test 分支内容编译,Nginx 映射到 dist 目录)

    branch --> 开发本地 local.abc.com (本地 web 服务)


    现在的问题是 branch 开发完成以后,需要测试同学看,但是测试同学不可能自己安装一套开发环境,所以我们需要把 branch 合到 test 上进行发布,这样测试才能看。测试测完成之后,把 test 合到 master 上发布。

    所以就导致了 某阶段 很多 branch 在 test 上。 然后 [要发布就得一起发布] 这种问题

    --------------------------------------------------

    昨天看了那个 git flow 的工作流以后,我是不是认为是这样?


    branch 合到 test, 然后 test 拉出 release 来进行 bug 修复。 这个时候测试环境 test.abc.com 应该对应的是这个 release 分支?

    release 通过之后,分别合到 test 和 master,这样理解对吗?

    我真正要改的是 让测试同学 正确浏览某个分支的 问题把?
    24 条回复    2020-12-16 09:44:27 +08:00
    qq73666
        1
    qq73666  
       2019-08-08 09:48:02 +08:00   ❤️ 1
    git flow 了解下
    MrUser
        2
    MrUser  
       2019-08-08 09:51:11 +08:00   ❤️ 1
    你需要 git flow 中的 release 分支,线上 bug 的分支名叫 hotfix,git flow 确实很适合你们
    LiuJiang
        3
    LiuJiang  
       2019-08-08 09:53:43 +08:00   ❤️ 1
    git flow 就好了
    release 测试分支和预发布分支
    master 主分支
    feature 功能开发分支
    hotfix 热修复分支
    hosaos
        4
    hosaos  
       2019-08-08 09:57:15 +08:00   ❤️ 1
    我们的做法是 多个开发分支 branch-a ,branch-b 合并到一个分支提测,某个分支的功能测试通过后单独发布然后合并到 master,bug 实在自己的开发分支修改然后合并到 test 测试
    nicevar
        5
    nicevar  
       2019-08-08 10:14:53 +08:00   ❤️ 1
    不就是 cherry-pick 的问题
    lincleejun
        6
    lincleejun  
       2019-08-08 10:42:41 +08:00   ❤️ 1
    一方面是 git flow 解决你分支管理的问题

    另外一方面你提到的是开发完毕后合并到 test 分支, 实际是不是该增加功能测试和集成测试?具体某个分支的功能测试完毕后才能进测试分支,测试分支做集成、回归。

    针对问题,这个问题由于是合并到 test 的, 用 git revert 指定的 merge 节点就好了啊
    ferock
        7
    ferock  
       2019-08-08 10:46:14 +08:00   ❤️ 1
    已经合进 test,突然某个 branch 在 test 环境测试不通过,或者不上线。 请问这个时候怎么办呢?
    比如:branch-a , branch-b ,branch-c 依次合进 test, 其中 branch-b 暂时不要了。


    这种模式下,无解。
    只能通过代码屏蔽掉对应的功能,因为 branch-b 代码已经在 test 里了,剥离出来又需要重新测试一遍,如果这时候 test 分支已经往前走了很远了,那更无法剥离。
    Woodywuuu
        8
    Woodywuuu  
       2019-08-08 10:56:53 +08:00   ❤️ 1
    小团队短流程建议用 TBD,之前强推 git flow,上手成本和操作成本都略高,选择最适合的,不要被技术绑架。
    现在是用 TBD+pr 的方式,运行良好。
    otakustay
        9
    otakustay  
       2019-08-08 11:05:14 +08:00   ❤️ 1
    git flow 根本不解决“分支需要合在一起才能完整测试”的场景,和楼主的需求对不上啊
    这事情如果分支不能单独测,必须合入后做集成测试,那上不了线就只能 revert 掉了,没啥办法
    menyakun
        10
    menyakun  
       2019-08-08 12:06:11 +08:00   ❤️ 1
    branch-b 不要了之后,之后的 commit 还要保留?

    git rebase, 然后 drop 掉 branch-b 的 commit,不过这样的话,集成测试就要重做了
    momocraft
        11
    momocraft  
       2019-08-08 12:11:37 +08:00   ❤️ 1
    revert

    听你描述更像是代码结构或管理问题,都不是 git 能解决
    msg7086
        12
    msg7086  
       2019-08-08 12:51:59 +08:00   ❤️ 1
    重做 test 分支。

    与其说是把 a b c 合并到 test 去测试,不如说新建一个 test-abc 去测试 abc 三个分支。如果 b 不要了,那无非就是重建一个 test-ac 去重测 ac 功能而已。

    Git 底下,分支只是一个会动的书签( Tag 则是一个不太会动的书签),不要去想着一个分支就是一个分支。分支可以随时随地新建,随时随地删除的。

    如果 test-abc 分支上有额外的改动提交,那么重做 test-ac 分支以后再把提交给 Rebase/Cherry Pick 过去就行了。
    iConsLii
        13
    iConsLii  
       2019-08-08 12:58:31 +08:00 via Android   ❤️ 1
    不能从 test 上拉新的功能分支把,我们都是从 master 上新拉分支
    WubWoofWolf
        14
    WubWoofWolf  
       2019-08-08 14:26:47 +08:00   ❤️ 1
    git flow 虽然繁琐,但长期迭代还是比较清晰的
    zqx
        15
    zqx  
       2019-08-08 14:48:03 +08:00 via Android   ❤️ 1
    test 分支是什么?难道你们的代码还区分测试和生产吗?我的意思是,只有环境才区分测试和生产吧?代码也要测试一套,生产一套?
    asuraa
        16
    asuraa  
       2019-08-08 14:51:02 +08:00   ❤️ 1
    推荐 git flow
    这个玩意很好用
    enenaaa
        17
    enenaaa  
       2019-08-08 15:05:14 +08:00   ❤️ 1
    branch 合并到 test 之后,branch 就不再继续使用了。 新 bug 在 test 上修复。
    xiaoyaojc
        18
    xiaoyaojc  
       2019-08-08 15:11:20 +08:00
    每次开发从 master 拉分支 branch a,然后都在 a 分支上开发,联调发到 dev 分支,提测合到 test 分支,如果上线,a 合到 master。
    firhome
        19
    firhome  
    OP
       2019-08-09 10:06:01 +08:00
    @qq73666
    @MrUser
    @LiuJiang
    @hosaos
    @nicevar
    @lincleejun
    @ferock
    @Woodywuuu
    @otakustay
    @menyakun
    @momocraft
    @msg7086
    @iConsLii
    @WubWoofWolf
    @zqx
    @luodaoyi
    @enenaaa
    @xiaoyaojc

    感谢各位的回复,我补充了内容。 大家看看我理解有问题吗?
    ferock
        20
    ferock  
       2019-08-09 10:41:39 +08:00   ❤️ 1
    @firhome #19

    看了一下你的问题,给 2 点建议

    1. 一般不叫 test 分支,而是叫 develop 分支,其实并不是纠结名字,而是,这个分支上的功能实现,就是所谓的 [开发版]
    2. 其实都是要测 3 次的,不管是功能第一次合并到在 develop ( test ) 上,还是最后拉出的 release 上。
    - 第一次测试,代码自测无问题,feature 分支。
    - 第二次测试,合并到 develop 分支,和其他功能一起测试。
    - 第三次测试,拉出的 release 分支,可能会在 develop 分支上截取某个时间点,作为 release,上面 A 功能满足,B 功能可能没有。需要最后回归测试一下。


    终告:国内公司不会遵循这种流程,因为太多的项目做了一半要砍掉。所以,从 git-flow 的流程上来说,无解!
    但,实际操作中,他们最后会选择:
    A 功能自己测。
    B 功能自己测。
    C 功能自己测。

    生产上最后的情况,A 发布,B 不发布,C 发布,怎么办?
    大家都上生产,出问题了就是事故,不出问题,下班回家。A+C-B 这样的代码永远都是会最后上生产了,测试才有机会测试这样的最终打死不修改版。
    msg7086
        21
    msg7086  
       2019-08-09 10:49:34 +08:00
    (说句实话,我觉得有些东西真的没办法只靠文字表述,最好是面对面教……这是我教人 Git 到现在最大的感受了。)
    firhome
        22
    firhome  
    OP
       2019-08-09 11:30:09 +08:00
    @ferock 非常感谢回复,你说的我理解了。但是还有两个问题需要帮忙解答一下。

    1. 合到 develop 分支后,出行 bug 是在哪个分支呢?直接 develop 分支 还是 feature 分支,又或者 拉个 release 出来改?

    2. 因为测试域名对应了 develop 分支的内容,那拉出来的 release 分支做回归测试的话,是不是还得部署一个该 release 分支的域名来让测试测?(因为测试同学机器上没有安装开发环境)
    ferock
        23
    ferock  
       2019-08-09 13:02:39 +08:00
    @firhome #22

    1. 按照 git-flow 流程 hotfix 是从 master 拉取的。完成发布后合并到 develop 和 master 内。

    解释一下版本号
    x.y.z

    x = 大版本号,上一版本和下一版本并不兼容
    y = 小版本号,上一版本和下一版本理应考虑兼容
    z = hotfix 号,解决各种 bug 问题。


    2. 按照你说的情况,是的!但按照 git-flow 规范,某个时间只应存在一个 release 版本。
    比如当前是 1.1 的 release,你还在测 1.2 的 release ?毫无意义啊。


    但还是那句话,国内公司基本没法按照这个流程来。
    simonlu9
        24
    simonlu9  
       2020-12-16 09:44:27 +08:00
    @firhome 我也遇到这个问题,想问下最后是怎么解决的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2770 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 12:30 · PVG 20:30 · LAX 05:30 · JFK 08:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.