V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
luxinfl
V2EX  ›  git

git 临时修改 bug 要怎么创建分支

  •  
  •   luxinfl · 2020-07-20 14:54:09 +08:00 · 4886 次点击
    这是一个创建于 1569 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前提:现在有 dev,test,master 分支。测试分支此时发现了一个 bug,但是当前有开发任务在 dev 分支上面,不想提交 dev 的代码。

    是不是可以这样处理:在 test 上面拉一 test-bug 个分支,在 test-bug 分支上面修改完之后,合并到 test 分支。 但是有个疑惑,此时 dev 分支肯定也是有 bug 的。这个时候我应该把 test-bug 分支改完的代码合并到 dev 还是从 test 分支拉代码回来?如果从 merge test-bug into dev,再 merge dev into test,不就相当于 bug 提交了两遍吗?

    38 条回复    2020-07-22 13:44:50 +08:00
    phpfpm
        1
    phpfpm  
       2020-07-20 14:57:10 +08:00
    你要修复到哪个分支,就从哪个分支 checkout 出来一个新的修复分支。

    如果这个 bug 影响到了你的 dev 的开发,那么你在提交测试完 test-bug 分支且合并到 test 之后,dev 合并 test 分支以修复这个 bug
    如果不影响,就放那吧

    不要直接合并 test-bug 进 dev,虽然不会提交两遍(参见 git 原理)
    但是会导致同一个提交有两个提交记录。

    记住,你的 dev 永远只 follow 一个分支准没错。
    Lonersun
        2
    Lonersun  
       2020-07-20 14:59:33 +08:00
    leonardyang
        3
    leonardyang  
       2020-07-20 15:09:12 +08:00
    我们以前的版本控制更复杂一些,除了你说的三个分支以外每次开发提的正式需求要从 master checkout 对应的 feature 分支,开发后再合并到 dev->test 提测,然后你说的这种情况就会在 dev 分支修改 bug 提交,再合并到 test 分支,而其他人没开发完的则还在他们的 feature 分支,不会影响
    luxinfl
        4
    luxinfl  
    OP
       2020-07-20 15:11:07 +08:00
    @phpfpm 你说的“dev 合并到 test 分支以修复这个 bug”,意思是切换到 dev 分支,然后从 test 归并过来吗?
    phpfpm
        5
    phpfpm  
       2020-07-20 15:12:56 +08:00
    @luxinfl ???
    多去看看 2 楼给的文档参考。

    在 dev 上分支 merge test
    luxinfl
        6
    luxinfl  
    OP
       2020-07-20 15:14:52 +08:00
    @phpfpm 我是看了提交记录,有两个一样的,我以为是重复提交了。。。反正现在合并代码的时候,经常有很多以前提过的代码,而且都是没变化的。。
    luxinfl
        7
    luxinfl  
    OP
       2020-07-20 15:15:07 +08:00
    @Lonersun 谢谢老铁
    guanerlin
        8
    guanerlin  
       2020-07-20 15:16:31 +08:00
    如果我理解没错,你应该 test 分支拉出来 test-bug 分支修复后,test-bug 合并进 test,然后 test 分支发版后(生产环境)会进入 master,master 会进 dev,dev 完成后会进 test,这个流程最好是这样的一个顺势:dev->test ( test-bug->test )->master->dev
    luxinfl
        9
    luxinfl  
    OP
       2020-07-20 15:27:14 +08:00
    @guanerlin 我们现在都还没有到 master 分支呢,只是 test 分支发现了 bug 。
    luxinfl
        10
    luxinfl  
    OP
       2020-07-20 15:28:19 +08:00
    @phpfpm 看了文档了,我们没用 git flow 。。。正常提交的流程都差不多
    ferock
        11
    ferock  
       2020-07-20 15:29:23 +08:00
    master 上拉一个 hotfix/xxx.xxx 版本的分支,修好了以后,发布
    发布完,合并到 master + develop 分支。

    参考 git-flow
    phpfpm
        12
    phpfpm  
       2020-07-20 16:08:13 +08:00
    @luxinfl 可以不用,但是要做正确的事情。。

    首先你要理解 git
    Kili9
        13
    Kili9  
       2020-07-20 16:17:55 +08:00
    我们流程是 develop 是用来线上发布的, master 是用来存稳定版本的. 如果需要开发一个新功能 从 master 拉一个功能开发分支: feature-xxxx-yyyyMMdd. 开发完成后提测阶段合并到 beta 分支, 提测完成后 feature-xxxx-yyyyMMdd 分支合并到 develop 用来发线上, 稳定后 develop 再合到 master 存档.
    joesonw
        14
    joesonw  
       2020-07-20 16:20:16 +08:00
    test-bug 合并后, 切到 dev, 把改动 cherrypick 进来直接推
    RoshanWu
        15
    RoshanWu  
       2020-07-20 16:26:50 +08:00
    cherry-pick 是正解。
    newtype0092
        16
    newtype0092  
       2020-07-20 16:34:13 +08:00
    @phpfpm 有几个问题请教下
    codereview 是在 feature 开发完成合并到 develop 分支时进行么?
    release 分支可以同时有多个么?(几个 feature 并行开发上线)
    如果一个大的 feature 到 release 时,在测试期间,有别的并行的小 feature 想上线怎么办?
    LiuJiang
        17
    LiuJiang  
       2020-07-20 16:57:03 +08:00
    从主分支上切一个 hotfix 分支
    luxinfl
        18
    luxinfl  
    OP
       2020-07-20 17:16:01 +08:00
    @joesonw 用了 cherrypick,但是我发现单独拉个 bug 分支,好像也不怎么影响。有 bug 就在 bug 分支上面改,dev 分支还是照常开发。。。我们反正没搞的太细致
    phpfpm
        19
    phpfpm  
       2020-07-20 18:24:52 +08:00   ❤️ 1
    @newtype0092

    1 codereview
    本质上 cr 是说不要让不合格的代码影响到其他人,所以合并到公共分支必须经过 cr
    2 release 分支的个数
    不行,一部分机器上 A 一部分机器上 B 么。。一般是梯度上线(小流量,灰度,每个层次有专门的分支)
    3 小 feature
    我们都是 release 分支不会持续太久(小流量也好灰度也好预发布也好持续太久必然导致功能分裂)
    所以要么等 release 测完再上(一般的,realease 正在被用着的时候不允许其他需求合并到 release )
    要么,后上的想上线先上的还没 ready 怎么办
    或者线上的想上线后上的还没 ready 又该怎么办
    不合并的自由度高一些。

    紧急修复直接上 master 。
    faceRollingKB
        20
    faceRollingKB  
       2020-07-20 19:24:31 +08:00
    我觉得需要从 dev 分支拉一个新的 bug 分支来处理,毕竟这个 bug 跟 test 分支的任务是无关的,最终合并分支时可以直接合并到 dev 也可以先合并到 test 再合并到 dev,这样更灵活
    faceRollingKB
        21
    faceRollingKB  
       2020-07-20 19:28:00 +08:00
    我把 test 、dev 搞反了,你说的方式是对的,bug 没有被提交两遍,最终的 commit history 中只有一个 commit 跟 bug 相关,其他的都只是 dev 的 commit,所以没关系
    railgun
        22
    railgun  
       2020-07-20 19:32:23 +08:00
    test 切出 bugfix 分支,改完后合并回 test,再 merge test 到 dev
    faceRollingKB
        23
    faceRollingKB  
       2020-07-20 19:33:01 +08:00
    可以看下文档 https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

    分支只是 commit history 中某个 commit 的引用,跟 svn 的方式不一样的
    orzorzorzorz
        24
    orzorzorzorz  
       2020-07-20 20:20:11 +08:00
    一般哪里有 bug 就改哪里。如果想避开提交记录的重复,可以从 dev checkout 出去,改完 squash 进 dev,然后 merge 进 test,这样看上去会清晰一些。
    admin7785
        25
    admin7785  
       2020-07-20 22:44:04 +08:00 via iPhone
    dev:git stash
    dev:git checkout test
    test:git checkout -b test-bug
    test-bug:git push
    test-bug:git checkout test
    test:git merge test-bug
    test:git checkout dev
    dev:git merge test

    如果哪一步不对,还请指正
    mritd
        26
    mritd  
       2020-07-21 08:22:36 +08:00 via iPhone
    遵循 gitflow 吧
    yizmaoaa
        27
    yizmaoaa  
       2020-07-21 09:16:40 +08:00
    提交到 dev,然后 cherry pick 到 test
    cco
        28
    cco  
       2020-07-21 09:34:10 +08:00
    从有 bug 的分支 checkout 出来一个 hostfix/xxxx 的分支,修改提测没问题合并到该分支以及基于该分支的其他分支。
    guanerlin
        29
    guanerlin  
       2020-07-21 11:37:19 +08:00
    @ferock 在测试阶段发现的 bug 是 bugfix
    guanerlin
        30
    guanerlin  
       2020-07-21 11:37:58 +08:00
    @luxinfl 我的意思是,流程是这样,所以你不要考虑这个分支往 dev 流动
    luxinfl
        31
    luxinfl  
    OP
       2020-07-21 11:38:21 +08:00
    @admin7785 额,最后一步和你不太一样,我是 dev:git merge test-bug
    luxinfl
        32
    luxinfl  
    OP
       2020-07-21 11:39:42 +08:00
    @faceRollingKB 最后从 dev 合到 test 的时候,会有 test-bug 合到 dev 的记录。。我记得是这样的
    luxinfl
        33
    luxinfl  
    OP
       2020-07-21 13:59:06 +08:00
    @faceRollingKB 看了一下,发现其实 test-bug 分支不需要去合到 dev 里面,dev 开发完直接合过去,有冲突解决冲突就行了
    luxinfl
        34
    luxinfl  
    OP
       2020-07-21 14:08:31 +08:00
    @admin7785 我看了 git 文档,好像不需要吧 test-bug 合并到 dev 分支,dev 改完之后,直接合到 test 就行了。然后可以拉新的 dev 分支
    faceRollingKB
        35
    faceRollingKB  
       2020-07-21 16:19:11 +08:00
    @luxinfl 最后合并三个分支 dev 、test 、bug 无论什么顺序结果都是一样的,你都需要处理 3 ~ 4 次 merge,一次解决 conflict,另外几次 fastforward 修改 pointer(同步分支引用),没有拉新 dev 分支的必要
    index90
        36
    index90  
       2020-07-21 16:52:01 +08:00
    你这种情况属于主干开发,分支发布。
    发布分支上发现了 bug,在发布分支上修复,并遴选到主干上。
    #33 有 conflict 应该尽早处理,等你过了几个星期开发完 dev 分支,估计都忘了那个 test-bug 了。

    前面有人提到 git flow,其实你的 test 分支相当于线上分支,以这样的视角参考 git flow 。
    admin7785
        37
    admin7785  
       2020-07-22 10:46:43 +08:00 via iPhone
    @luxinfl #34 但是不应该是立即切个 test-bug 出来解决 bug 吗,解决完之后还要在 dev 做第二次修改吗?

    看了你 33 楼的回复,应该是没问题的,合并的时候解决冲突就行,最后一步合到 dev,可以避免解决冲突这一步,都差不多,我日常中会选择合并。
    luxinfl
        38
    luxinfl  
    OP
       2020-07-22 13:44:50 +08:00
    @admin7785 反正公司也没人会关注提交日志什么的,现在 bug 分支就两头合,无所谓了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5528 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 08:33 · PVG 16:33 · LAX 00:33 · JFK 03:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.