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