这个问题以前我在用SVN的时候就想过，但当时没想明白，也没遇到出bug的时候。
现在学习Git，同样有这个疑问存在，就提出来。
问题：
在合并分支的时候，如果没有冲突，Git自动合并的代码会不会有bug？
因为Git在合并时检测到的冲突都是编辑上的冲突，比如两次编辑是否在同一行上，两次编辑是否有相反的操作（一个增加一个删除相同的代码），显然，Git并不也无法关心代码本身的逻辑。
所以我认为合并之后应该去检查代码的正确性，相当于每次合并之后都需要验证两份分支所解决的问题在合并后是否又处于未解决的状态，以及是否产生了新了Bug，那这工作量就大了啊？
不知道各位在实际使用中会这么去检查吗？
你如果有百度过，应该会看到类似的信息：虽然你的开发是在branch上，但是为了确保不和主干偏差太远，需要经常由trunk合并到branch的。
如果一个团队遵守流程，就不会有太大的问题。
如果多人编辑同一处代码，Git会报出合并冲突，需人为解决冲突，Git无法知道要怎么处理这些代码，这是无法避免的。实际多人协作的项目中，大家一般会分模块开发，尽量避免改动同一处文件；更改公共模块前，先更新。
如果合并之后未报冲突，那就是没有同一处代码被多少更改，没必要去检查合并的正解性。至于合并的代码引入了逻辑上的bug，那就需要review了。
当然能啊，一个功能要要用到 a b c 三个方法， 分别三个人去改那三个方法（假设三人都不知道别人改了）； 这种情况，git是不会认为是冲突的；但是你还能保证这个功能还是三人各自想要的嘛？
不会，因为git合并有两种情况，第一：一个文件里面，同一段代码被两个人同时改动过，git合并是会报冲突。需要人工合并。第二：如果两个人改了同一个文件的不同代码段。git会自动合并。有没有bug那完全是写代码的人的问题。有bug，合并之后自然有bug。没有bug，合并之后也不会有bug。不能乱甩锅！
Git躺着也中枪，奔泪说：我只负责代码合并，bug是人写的啊，这锅偶不背。。。。。。
凡事无绝对，没有冲突能合并出bug那只能说你中奖了
这个不叫bug，叫
冲突。解决冲突的方案：使用别人的版本
使用自己的版本
手动合并。
而规避冲突的一个很常用的方法是：修改前，先
pull本地分支，减少冲突几率额，git只是个版本管理工具，合并代码，出现bug，那是你们项目组自己代码问题啊，根本就不是git的锅，你的这个问题，应该可以通过写测试代码来处理。
是有这个可能的，相当于中奖