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

版本控制系统的合并操作,会引入新 bug 吗?

  •  
  •   ybw · 2020-03-17 12:29:47 +08:00 via Android · 2852 次点击
    这是一个创建于 1473 天前的主题,其中的信息可能已经有所发展或是发生改变。

    比如前年你拉了一个分支,提交了一堆东西。

    今年想起来把他合并了,这个过程会不会引入新 bug ?

    会的话,几率有多大。

    26 条回复    2020-03-18 12:19:04 +08:00
    xiri
        1
    xiri  
       2020-03-17 12:33:59 +08:00 via Android
    你合并分支不要解决冲突的吗
    ybw
        2
    ybw  
    OP
       2020-03-17 12:35:16 +08:00 via Android
    @xiri 解决。单单只处理程序自动报错的冲突文件,能不能避免引入未知 bug。
    wsxyeah
        3
    wsxyeah  
       2020-03-17 12:38:41 +08:00 via iPhone
    可以强制 fast foword 才能 merge
    Sharuru
        4
    Sharuru  
       2020-03-17 12:40:44 +08:00
    就个人多年使用下来的经验来谈,合并后发生 bug 几乎都是由于冲突操作不正确(一股脑的选择某一侧的代码),或者本身业务逻辑考虑不周密( if 判断不正确)导致的。

    单就 merge 本身,自动合并的情况下没碰到过引入了 bug 的经历。
    ayase252
        5
    ayase252  
       2020-03-17 12:40:47 +08:00 via iPhone
    可能会,冲突解决不好就会
    ybw
        6
    ybw  
    OP
       2020-03-17 12:41:52 +08:00 via Android
    @Sharuru 这种自动操作,会引入全新 bug 的可能性,无法排除,总觉得不太舒服。
    Sharuru
        7
    Sharuru  
       2020-03-17 12:43:50 +08:00   ❤️ 1
    @ybw #6 无论怎么做都有可能性。

    自己人肉合并也可能因为复制错了导致 bug。
    不放心完全可以每次合并后看看合并结果,再说了,还有各种单元测试、集成测试等各种技术来做各种保护。
    guyeu
        8
    guyeu  
       2020-03-17 13:57:32 +08:00
    答案显然是肯定的,只要进行修改,就不可避免会有 bug 的隐患。目前最有效的方案就是人工 review+测试保护,对任何修改都是适用的。
    pocarisweat
        9
    pocarisweat  
       2020-03-17 14:11:08 +08:00
    有可能,但概率比较小。所以比较大的改动 merge 之前一定要认真 review 一下,同时如果有单元测试就会放心很多。
    passerbytiny
        10
    passerbytiny  
       2020-03-17 14:23:22 +08:00   ❤️ 1
    会,几率跟版本控制系统本身无关。版本控制系统只是用来控制源代码的存储和协同修改的,跟 bug 唯一有的关系是“任何修改都可能引入 bug”。

    要想不引入新 bug,靠的是测试和 review。

    题外话,cvs、svn 是版本控制系统(人家名字中就带着 version ),但 git 就不再适合归入版本控制系统了。git 从名字到组成都没有 version 的概念,连顺序历史的概念都是人为加上去的。
    aleung
        11
    aleung  
       2020-03-17 14:24:09 +08:00
    前年拉分支...今年合并...

    如果主干还在活跃开发的话,那我可以说大几率会发生问题,就看你的测试覆盖率怎么样了。

    分支生命周期不应该太长,就算不得不长期维护,也应该定期 rebase (或者 merge upstream )以跟上 upstream 的改动。
    aleung
        12
    aleung  
       2020-03-17 14:26:35 +08:00
    @passerbytiny 你说 git 不适合归入版本控制系统,那它应该归为什么啊?

    https://git-scm.com/

    > Git is a free and open source **distributed version control system** designed to handle everything from small to very large projects with speed and efficiency.
    minglanyu
        13
    minglanyu  
       2020-03-17 14:28:29 +08:00
    可以试试 cherry pick,选择你要的几个提交。
    冲突少就 pick 过来,冲突实在多不如慢慢增删过来,分支删掉。
    koAlaPierce
        14
    koAlaPierce  
       2020-03-17 14:33:58 +08:00
    不会引入,合并操作的结果是可预知的,既然是可预知的,出现 bug 只能是操作人的问题,而不是版本控制系统的问题
    ybw
        15
    ybw  
    OP
       2020-03-17 14:54:19 +08:00
    @koAlaPierce 版本控制系统, 你操作, 和我操作, 还能有区别. 软件还会看人下菜碟?
    只讨论自动合并无冲突报错的那些文件
    mercury233
        16
    mercury233  
       2020-03-17 15:00:04 +08:00
    比如你有个全局变量 a,master 里已经把 a 的名字改成 b 了,你前年的分支新建了个类里面用到了 a,直接合并不会有冲突,但明显不行。
    passerbytiny
        17
    passerbytiny  
       2020-03-17 15:01:15 +08:00
    @aleung #12 URL 本身就带了它的定义——SCM ( Software Configuration Management,软件配置管理)。软件配置管理是软件工程学的正式名词,版本控制系统 VCS 算是俗名或早期名称,二者通常无须区分,但 Git 当中并没有版本号的概念,再叫它版本控制系统真得不合适。
    passerbytiny
        18
    passerbytiny  
       2020-03-17 15:07:08 +08:00
    @ybw #15 git 这里,两个分支共同修改一个文件则冲突; svn、cvs 那里,两个分支(或者本地与服务器)统统修改一个文件且无法自动合并则冲突。有冲突并不一定会引起 bug,比如两个分支都修改了同一个文件但只修改了注释。没冲突也不表示不会引起 bug,比如 A 分支仅修改上层代码 B 分支修改了前者依赖的底层代码。
    tyrantZhao
        19
    tyrantZhao  
       2020-03-17 15:13:25 +08:00
    会,任何改动都有可能引入 bug
    BUPTGuo
        20
    BUPTGuo  
       2020-03-17 16:12:15 +08:00
    是否会引入 bug,取决于对代码逻辑的控制,和程序正确性的验证啊

    和是否 merge 没关系吧
    ybw
        21
    ybw  
    OP
       2020-03-17 17:40:46 +08:00 via Android
    @BUPTGuo merge 会自动合并代码
    zunceng
        22
    zunceng  
       2020-03-17 17:50:31 +08:00
    当然会了 要不干嘛要人来操作!!!
    yeze322
        23
    yeze322  
       2020-03-17 17:57:32 +08:00
    你这种情况确定一定会有 bug。前年的分支竟然还可以和 master 合并,无非两种情况:
    1. 模块边界特别清晰,接口两年时间保持不变,两个分支可以正交。那不会 bug (基本不可能)
    2. 强行 merge,只解决文件表层的冲突 => 后患无穷
    msg7086
        24
    msg7086  
       2020-03-18 09:21:42 +08:00
    前年你拉了个分支,今年你合并,如果前年到今年别人没有提交的话,合并当然没问题。
    只要别人有任何一丁点的提交,你的合并都可能引入新问题。
    这甚至和是否冲突都没关系。

    所以废弃分支重新启用的时候,一来必须 Rebase,二来必须手动测试,通过了才能合并。
    SoloCompany
        25
    SoloCompany  
       2020-03-18 11:45:10 +08:00
    按级别从低到高, 越往后越糟糕因为发现难度再增加
    首先, merge 可能发生 conflict
    其次, auto merge 成功可能发生 build fail (任何一端引入了 compile uncompatible changes, 比如, 参数个数 /类型改变)
    再次, build 成功, 运行时暴露问题 (任何一段引入了 runtime breaking change, 方法签名完全一样但参数的含义被改变)

    不要过于相信工具, 工具自动化只是协助你做事情, 而不能替代所有工作, 即使写了大量 UT 都不一定能防止这些事情的发生, 但有 UT 肯定要比没有好
    jixiangqd
        26
    jixiangqd  
       2020-03-18 12:19:04 +08:00
    工具懂你的业务么?也许未来 AI 版本控制可以做到?:#
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2885 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 11:21 · PVG 19:21 · LAX 04:21 · JFK 07:21
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.