git 两个分支合并的时候，如何保证代码运行正常？

[sugarkeek]

比如说 M 和 B 分支，B 基于 M 新建里一个分支，M 和 B 各自开发着不同的模块。有几个问题：

1. M 和 B 的虽然在开发不同的模块，但是可能会动到同一模块的地方，比如说配置，那么合并的时候不仅是说合并不同的模块，还得解决同一模块冲突的地方。

2. git 是有冲突对比的，包括用的 GUI 软件都有非常直观的冲突对比，通过几次合并发现了一些问题，git 是能解决文本冲突的对比，但是到了代码运行时，有时也会出错，即使我们觉得某个地方冲突了，采用哪方的代码才是正确的。

但是程序不能说有时出错啊，所以代码在开发的过程中，心中总是有种隐隐的担心合并的代码会出现问题。git 很强大，帮助我们管理大量的代码，但是就好像海下的冰山一样，很多东西我们都无法预料的到。

3. 总结一下就是，git 能解决代码不同，但是不能保证合并的代码正常运行。

顺便再吐槽一下 Jetbrains 家之前的 git 的本地包 rebase 的翻译（现在忘记怎么翻译的了，衍入还是合并好像，反正容易搞混），一时和 merge 搞混，点了之后才发现是 rebase，悔恨交加，后面换回英文版了。不过在其他非主力的软件如 webstorm 本地包还没卸载，更新了最新版之后看了看 rebase 单词换回英文来。所以说一个信达雅的翻译确实很难啊。

[wednesdayco]

谁合并,谁解决冲突吧……看看 git flow 规范?

[baiyi]

git 解决的就是代码冲突，你需要的是持续集成。

[imdong]

测试跟上,感觉写测试比写代码还难,工作量也很大.

但是可以有效减少楼主的问题.

[yanqiyu]

git 只是在文本层面处理代码，它管不到代码里面的逻辑，你需要的是测试用例

[teddy2725]

测试覆盖够了就没事，单元测试，功能测试，集成测试。

[no1xsyzy]

测试
有时会注意到持续集成，主要是测试通常是集成的一环

还有一方面，就是（尽量）不要两个人同时动一片逻辑。
最糟糕的就是一个人为某个方法添加了新的特性，另一个人重构了这个方法…… 那几乎必有一个人打回重做。
开源的自组织结构来说，多半会先提 issue 来宣告自己在动这块。

这个翻译确实有问题，git rebase 应当作为术语不翻译。
“变基” 这个翻译也不够牢靠，而且作为中文也很怪异。
不过这中英文混杂…… 大刘直呼内行。

[TuringGunner]

后合并的负责 rebase 解决冲突，然后把测试再跑一遍

[Chenamy2017]

这和 git 没有关系，动了代码就要测试，不管是人工修改的还是 git 自动解决冲突的。

[msg7086]

当然靠集成测试了。两个分支合并产生冲突的话，不管是取其中一个分支的代码，还是把两个分支的修改合并在一起，都有可能导致代码出问题。

简单说就是后合并的分支需要重做。

[soulmt]

git 只负责冲突，不负责代码能不能跑起来，所以合并只是发布的第一步，应该有测试回归测试这一环节。

[crclz]

新建一个临时分支用于：1. 合并冲突 2. 运行单元测试、各种测试
测试通过后，将该分支并入 master 分支。如果需要部署，就将 master 分支并入 release 分支。

[fucUup]

我们的开源项目, 全球有 2 万个 git 账户在全球 7*24 协作, 没有你的糟心事, 都是水平问题, 合并的地方该是 true 还是 false, 你心里没有一点 B*****

[BeautifulSoap]

公司的一个项目，提 pr 会用 github actions 自动进行单元测试，不通过直接打回，同时还会对提交的代码进行 linter 检查，不合规范也是打回，并且要求提交的 pr 细粒度必须小。但问题是，pr 小细粒度和单元测试必须通过经常是冲突的，感觉一个功能完成并合并需要的时间成倍增长

不过有得必有失，作为项目来说这么做的确是有好处的

[fucUup]

@BeautifulSoap en???? 意思就是说小颗粒度会 break 代码??? 这不合理. 是人的问题.

[sugarkeek]

@wednesdayco
@TuringGunner
@msg7086
好，会尝试运用这种思想在项目实践里，我去学习学习 git flow

@imdong
@teddy2725
@Chenamy2017
@soulmt
测试确实很重要啊，也在想办法提高测试的效率

@baiyi 也是在追求这种工作流

@yanqiyu 嗯嗯，看来也只能在测试上下功夫

@no1xsyzy 谢谢朋友的耐心指教，在测试上多下功夫。

@crclz 谢谢朋友这种新思路

@fucUup 相信 git 的潜力，我确实水平还有提升的空间，都是现学现用。

@BeautifulSoap 感谢分享 git 在公司中的实践，我也是想 git 帮助项目更好的进行。

[jxlwqq]

git 分支合并的原则是：“从哪来，回哪去”。
代码是否正常运行的问题，就需要单元测试覆盖了。只要单元测试+code review 没问题，就可以合并。至于功能性的测试或者其他外部测试，就需要作为测试角色的人来做了。

[lizytalk]

单元测试

[yogogo]

M 和 B 的虽然在开发不同的模块，但是可能会动到同一模块的地方，比如说配置，那么合并的时候不仅是说合并不同的模块，还得解决同一模块冲突的地方。
------------------------------------------
这样分支是不是太混乱了，要是每个开发人员一个分支，那合并不得要出大事。不是应该要按开发版本做分支吗？

[hantsy]

任何合并到 Master 直接跑 CI 测试就完了。

[hackape]

这事儿的本质跟 git 没有任何关系。

即便是不分叉、线性地去开发，想象一下张三开发 A 模块，改了通用服务 C，提交完了，然后李四接着开发 B 模块，然后也改了服务 C 。你看这里面没有分叉再合并、产生冲突的过程，但也不能保证李四改完了的 C 就完全不出问题，除非李四充分理解自己的改动，这包括他需要去看张三的那部分代码。

合并出现冲突，本质上面对的问题还是两个人分别改了同个东西如何保证不出错，要么是李四解决冲突的时候好好读代码，要么把张三叫过来，大家一起 review 一下。

再退一步讲，哪怕只有张三一个人写东西，照样不能保证不出错，相信大家都有过看不懂自己的老代码的经验。

所以说这事儿跟 git 没有半毛钱关系，而你说的问题，别的楼层提到的 CI/CD, TDD 都是有效的方法（如果不流于形式、好好执行的话），然而还是那句话 there's no silver bullet，这个话题没有最终答案的。