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

[ybw]

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

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

会的话，几率有多大。

[xiri]

你合并分支不要解决冲突的吗

[ybw]

@xiri 解决。单单只处理程序自动报错的冲突文件，能不能避免引入未知 bug。

[wsxyeah]

可以强制 fast foword 才能 merge

[Sharuru]

就个人多年使用下来的经验来谈，合并后发生 bug 几乎都是由于冲突操作不正确（一股脑的选择某一侧的代码），或者本身业务逻辑考虑不周密（ if 判断不正确）导致的。

单就 merge 本身，自动合并的情况下没碰到过引入了 bug 的经历。

[ayase252]

可能会，冲突解决不好就会

[ybw]

@Sharuru 这种自动操作，会引入全新 bug 的可能性，无法排除，总觉得不太舒服。

[Sharuru]

@ybw #6 无论怎么做都有可能性。

自己人肉合并也可能因为复制错了导致 bug。
不放心完全可以每次合并后看看合并结果，再说了，还有各种单元测试、集成测试等各种技术来做各种保护。

[guyeu]

答案显然是肯定的，只要进行修改，就不可避免会有 bug 的隐患。目前最有效的方案就是人工 review+测试保护，对任何修改都是适用的。

[pocarisweat]

有可能，但概率比较小。所以比较大的改动 merge 之前一定要认真 review 一下，同时如果有单元测试就会放心很多。

[passerbytiny]

会，几率跟版本控制系统本身无关。版本控制系统只是用来控制源代码的存储和协同修改的，跟 bug 唯一有的关系是“任何修改都可能引入 bug”。

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

题外话，cvs、svn 是版本控制系统（人家名字中就带着 version ），但 git 就不再适合归入版本控制系统了。git 从名字到组成都没有 version 的概念，连顺序历史的概念都是人为加上去的。

[aleung]

前年拉分支...今年合并...

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

分支生命周期不应该太长，就算不得不长期维护，也应该定期 rebase （或者 merge upstream ）以跟上 upstream 的改动。

[aleung]

@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]

可以试试 cherry pick，选择你要的几个提交。
冲突少就 pick 过来，冲突实在多不如慢慢增删过来，分支删掉。

[koAlaPierce]

不会引入，合并操作的结果是可预知的，既然是可预知的，出现 bug 只能是操作人的问题，而不是版本控制系统的问题

[ybw]

@koAlaPierce 版本控制系统, 你操作, 和我操作, 还能有区别. 软件还会看人下菜碟?
只讨论自动合并无冲突报错的那些文件

[mercury233]

比如你有个全局变量 a，master 里已经把 a 的名字改成 b 了，你前年的分支新建了个类里面用到了 a，直接合并不会有冲突，但明显不行。

[passerbytiny]

@aleung #12 URL 本身就带了它的定义——SCM （ Software Configuration Management，软件配置管理）。软件配置管理是软件工程学的正式名词，版本控制系统 VCS 算是俗名或早期名称，二者通常无须区分，但 Git 当中并没有版本号的概念，再叫它版本控制系统真得不合适。

[passerbytiny]

@ybw #15 git 这里，两个分支共同修改一个文件则冲突； svn、cvs 那里，两个分支（或者本地与服务器）统统修改一个文件且无法自动合并则冲突。有冲突并不一定会引起 bug，比如两个分支都修改了同一个文件但只修改了注释。没冲突也不表示不会引起 bug，比如 A 分支仅修改上层代码 B 分支修改了前者依赖的底层代码。

[tyrantZhao]

会，任何改动都有可能引入 bug

[BUPTGuo]

是否会引入 bug，取决于对代码逻辑的控制，和程序正确性的验证啊

和是否 merge 没关系吧