这是一个创建于 2229 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如前年你拉了一个分支，提交了一堆东西。
今年想起来把他合并了，这个过程会不会引入新 bug ？
会的话，几率有多大。
 | 1 xiri 2020 年 3 月 17 日 via Android 你合并分支不要解决冲突的吗 |
 | 3 wsxyeah 2020 年 3 月 17 日 via iPhone 可以强制 fast foword 才能 merge |
 | 4 Sharuru 2020 年 3 月 17 日 就个人多年使用下来的经验来谈，合并后发生 bug 几乎都是由于冲突操作不正确（一股脑的选择某一侧的代码），或者本身业务逻辑考虑不周密（ if 判断不正确）导致的。 单就 merge 本身，自动合并的情况下没碰到过引入了 bug 的经历。 |
 | 5 ayase252 2020 年 3 月 17 日 via iPhone 可能会，冲突解决不好就会 |
 | 6 ybw OP Sharuru 这种自动操作，会引入全新 bug 的可能性，无法排除，总觉得不太舒服。 |
| 7 Sharuru 2020 年 3 月 17 日  1 |
 | 8 guyeu 2020 年 3 月 17 日 答案显然是肯定的，只要进行修改，就不可避免会有 bug 的隐患。目前最有效的方案就是人工 review+测试保护，对任何修改都是适用的。 |
 | 9 pocarisweat 2020 年 3 月 17 日 有可能，但概率比较小。所以比较大的改动 merge 之前一定要认真 review 一下，同时如果有单元测试就会放心很多。 |
 | 10 passerbytiny 2020 年 3 月 17 日 1 会，几率跟版本控制系统本身无关。版本控制系统只是用来控制源代码的存储和协同修改的，跟 bug 唯一有的关系是“任何修改都可能引入 bug”。 要想不引入新 bug，靠的是测试和 review。 题外话，cvs、svn 是版本控制系统（人家名字中就带着 version ），但 git 就不再适合归入版本控制系统了。git 从名字到组成都没有 version 的概念，连顺序历史的概念都是人为加上去的。 |
 | 11 aleung 2020 年 3 月 17 日 前年拉分支...今年合并... 如果主干还在活跃开发的话，那我可以说大几率会发生问题，就看你的测试覆盖率怎么样了。 分支生命周期不应该太长，就算不得不长期维护，也应该定期 rebase （或者 merge upstream ）以跟上 upstream 的改动。 |
| 12 aleung 2020 年 3 月 17 日 @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. |
 | 13 minglanyu 2020 年 3 月 17 日 可以试试 cherry pick，选择你要的几个提交。 冲突少就 pick 过来，冲突实在多不如慢慢增删过来，分支删掉。 |
 | 14 koAlaPierce 2020 年 3 月 17 日 不会引入，合并操作的结果是可预知的，既然是可预知的，出现 bug 只能是操作人的问题，而不是版本控制系统的问题 |
| 15 ybw OP @koAlaPierce 版本控制系统, 你操作, 和我操作, 还能有区别. 软件还会看人下菜碟? 只讨论自动合并无冲突报错的那些文件 |
 | 16 mercury233 2020 年 3 月 17 日 比如你有个全局变量 a，master 里已经把 a 的名字改成 b 了，你前年的分支新建了个类里面用到了 a，直接合并不会有冲突，但明显不行。 |
| 17 passerbytiny 2020 年 3 月 17 日 @aleung #12 URL 本身就带了它的定义SCM （ Software Configuration Management，软件配置管理）。软件配置管理是软件工程学的正式名词，版本控制系统 VCS 算是俗名或早期名称，二者通常无须区分，但 Git 当中并没有版本号的概念，再叫它版本控制系统真得不合适。 |
| 18 passerbytiny 2020 年 3 月 17 日 @ybw #15 git 这里，两个分支共同修改一个文件则冲突； svn、cvs 那里，两个分支（或者本地与服务器）统统修改一个文件且无法自动合并则冲突。有冲突并不一定会引起 bug，比如两个分支都修改了同一个文件但只修改了注释。没冲突也不表示不会引起 bug，比如 A 分支仅修改上层代码 B 分支修改了前者依赖的底层代码。 |
 | 19 GeminiPro 2020 年 3 月 17 日 会，任何改动都有可能引入 bug |
 | 20 BUPTGuo 2020 年 3 月 17 日 是否会引入 bug，取决于对代码逻辑的控制，和程序正确性的验证啊 和是否 merge 没关系吧 |
21 ybw OP @BUPTGuo merge 会自动合并代码 |
 | 22 zunceng 2020 年 3 月 17 日 当然会了 要不干嘛要人来操作！！！ |
 | 23 yeze322 2020 年 3 月 17 日 你这种情况确定一定会有 bug。前年的分支竟然还可以和 master 合并，无非两种情况： 1. 模块边界特别清晰，接口两年时间保持不变，两个分支可以正交。那不会 bug （基本不可能） 2. 强行 merge，只解决文件表层的冲突 => 后患无穷 |
 | 24 msg7086 2020 年 3 月 18 日 前年你拉了个分支，今年你合并，如果前年到今年别人没有提交的话，合并当然没问题。 只要别人有任何一丁点的提交，你的合并都可能引入新问题。 这甚至和是否冲突都没关系。 所以废弃分支重新启用的时候，一来必须 Rebase，二来必须手动测试，通过了才能合并。 |
 | 25 SoloCompany 2020 年 3 月 18 日 按级别从低到高, 越往后越糟糕因为发现难度再增加 首先, merge 可能发生 conflict 其次, auto merge 成功可能发生 build fail (任何一端引入了 compile uncompatible changes, 比如, 参数个数 /类型改变) 再次, build 成功, 运行时暴露问题 (任何一段引入了 runtime breaking change, 方法签名完全一样但参数的含义被改变) 不要过于相信工具, 工具自动化只是协助你做事情, 而不能替代所有工作, 即使写了大量 UT 都不一定能防止这些事情的发生, 但有 UT 肯定要比没有好 |
 | 26 jixiangqd 2020 年 3 月 18 日 工具懂你的业务么？也许未来 AI 版本控制可以做到？：# |
Select Language