这是一个创建于 1403 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如说 M 和 B 分支，B 基于 M 新建里一个分支，M 和 B 各自开发着不同的模块。有几个问题：
1. M 和 B 的虽然在开发不同的模块，但是可能会动到同一模块的地方，比如说配置，那么合并的时候不仅是说合并不同的模块，还得解决同一模块冲突的地方。
2. git 是有冲突对比的，包括用的 GUI 软件都有非常直观的冲突对比，通过几次合并发现了一些问题，git 是能解决文本冲突的对比，但是到了代码运行时，有时也会出错，即使我们觉得某个地方冲突了，采用哪方的代码才是正确的。
但是程序不能说有时出错啊，所以代码在开发的过程中，心中总是有种隐隐的担心合并的代码会出现问题。git 很强大，帮助我们管理大量的代码，但是就好像海下的冰山一样，很多东西我们都无法预料的到。
3. 总结一下就是，git 能解决代码不同，但是不能保证合并的代码正常运行。
顺便再吐槽一下 Jetbrains 家之前的 git 的本地包 rebase 的翻译（现在忘记怎么翻译的了，衍入还是合并好像，反正容易搞混），一时和 merge 搞混，点了之后才发现是 rebase，悔恨交加，后面换回英文版了。不过在其他非主力的软件如 webstorm 本地包还没卸载，更新了最新版之后看了看 rebase 单词换回英文来。所以说一个信达雅的翻译确实很难啊。
1. M 和 B 的虽然在开发不同的模块，但是可能会动到同一模块的地方，比如说配置，那么合并的时候不仅是说合并不同的模块，还得解决同一模块冲突的地方。
2. git 是有冲突对比的，包括用的 GUI 软件都有非常直观的冲突对比，通过几次合并发现了一些问题，git 是能解决文本冲突的对比，但是到了代码运行时，有时也会出错，即使我们觉得某个地方冲突了，采用哪方的代码才是正确的。
但是程序不能说有时出错啊，所以代码在开发的过程中，心中总是有种隐隐的担心合并的代码会出现问题。git 很强大，帮助我们管理大量的代码，但是就好像海下的冰山一样，很多东西我们都无法预料的到。
3. 总结一下就是，git 能解决代码不同，但是不能保证合并的代码正常运行。
顺便再吐槽一下 Jetbrains 家之前的 git 的本地包 rebase 的翻译（现在忘记怎么翻译的了，衍入还是合并好像，反正容易搞混），一时和 merge 搞混，点了之后才发现是 rebase，悔恨交加，后面换回英文版了。不过在其他非主力的软件如 webstorm 本地包还没卸载，更新了最新版之后看了看 rebase 单词换回英文来。所以说一个信达雅的翻译确实很难啊。
 |
1
wednesdayco 2021-02-23 11:16:41 +08:00
谁合并,谁解决冲突吧……看看 git flow 规范?
|
 |
2
baiyi 2021-02-23 11:18:15 +08:00
git 解决的就是代码冲突，你需要的是持续集成。
|
 |
3
imdong 2021-02-23 11:21:39 +08:00
测试跟上,感觉写测试比写代码还难,工作量也很大.
但是可以有效减少楼主的问题. |
 |
4
yanqiyu 2021-02-23 11:26:18 +08:00 via Android  1
git 只是在文本层面处理代码，它管不到代码里面的逻辑，你需要的是测试用例
|
 |
5
teddy2725 2021-02-23 11:27:23 +08:00 2
测试覆盖够了就没事，单元测试，功能测试，集成测试。
|
 |
6
no1xsyzy 2021-02-23 11:38:34 +08:00
测试
有时会注意到持续集成，主要是测试通常是集成的一环 还有一方面，就是（尽量）不要两个人同时动一片逻辑。 最糟糕的就是一个人为某个方法添加了新的特性，另一个人重构了这个方法…… 那几乎必有一个人打回重做。 开源的自组织结构来说，多半会先提 issue 来宣告自己在动这块。 这个翻译确实有问题，git rebase 应当作为术语不翻译。 “变基” 这个翻译也不够牢靠，而且作为中文也很怪异。 不过这中英文混杂…… 大刘直呼内行。 |
 |
7
TuringGunner 2021-02-23 11:42:08 +08:00
后合并的负责 rebase 解决冲突，然后把测试再跑一遍
|
 |
8
Chenamy2017 2021-02-23 11:46:27 +08:00
这和 git 没有关系，动了代码就要测试，不管是人工修改的还是 git 自动解决冲突的。
|
 |
9
msg7086 2021-02-23 11:47:36 +08:00
当然靠集成测试了。两个分支合并产生冲突的话，不管是取其中一个分支的代码，还是把两个分支的修改合并在一起，都有可能导致代码出问题。
简单说就是后合并的分支需要重做。 |
 |
10
soulmt 2021-02-23 11:50:39 +08:00
git 只负责冲突，不负责代码能不能跑起来，所以合并只是发布的第一步，应该有测试回归测试这一环节。
|
 |
11
crclz 2021-02-23 12:03:03 +08:00
新建一个临时分支用于：1. 合并冲突 2. 运行单元测试、各种测试
测试通过后，将该分支并入 master 分支。如果需要部署，就将 master 分支并入 release 分支。 |
 |
12
fucUup 2021-02-23 12:15:45 +08:00
我们的开源项目, 全球有 2 万个 git 账户在全球 7*24 协作, 没有你的糟心事, 都是水平问题, 合并的地方该是 true 还是 false, 你心里没有一点 B*****
|
 |
13
BeautifulSoap 2021-02-23 12:22:53 +08:00
公司的一个项目，提 pr 会用 github actions 自动进行单元测试，不通过直接打回，同时还会对提交的代码进行 linter 检查，不合规范也是打回，并且要求提交的 pr 细粒度必须小。但问题是，pr 小细粒度和单元测试必须通过经常是冲突的，感觉一个功能完成并合并需要的时间成倍增长
不过有得必有失，作为项目来说这么做的确是有好处的 |
|
14
fucUup 2021-02-23 12:30:46 +08:00
@BeautifulSoap en???? 意思就是说小颗粒度会 break 代码??? 这不合理. 是人的问题.
|
 |
15
sugarkeek OP @wednesdayco
@TuringGunner @msg7086 好，会尝试运用这种思想在项目实践里，我去学习学习 git flow @imdong @teddy2725 @Chenamy2017 @soulmt 测试确实很重要啊，也在想办法提高测试的效率 @baiyi 也是在追求这种工作流 @yanqiyu 嗯嗯，看来也只能在测试上下功夫 @no1xsyzy 谢谢朋友的耐心指教，在测试上多下功夫。 @crclz 谢谢朋友这种新思路 @fucUup 相信 git 的潜力，我确实水平还有提升的空间，都是现学现用。 @BeautifulSoap 感谢分享 git 在公司中的实践，我也是想 git 帮助项目更好的进行。 |
 |
16
jxlwqq 2021-02-23 13:17:02 +08:00
git 分支合并的原则是：“从哪来，回哪去”。
代码是否正常运行的问题，就需要单元测试覆盖了。只要单元测试+code review 没问题，就可以合并。至于功能性的测试或者其他外部测试，就需要作为测试角色的人来做了。 |
 |
17
lizytalk 2021-02-23 13:20:43 +08:00
单元测试
|
 |
18
yogogo 2021-02-23 13:20:44 +08:00
M 和 B 的虽然在开发不同的模块，但是可能会动到同一模块的地方，比如说配置，那么合并的时候不仅是说合并不同的模块，还得解决同一模块冲突的地方。
------------------------------------------ 这样分支是不是太混乱了，要是每个开发人员一个分支，那合并不得要出大事。不是应该要按开发版本做分支吗？ |
 |
19
hantsy 2021-02-23 13:23:37 +08:00 1
任何合并到 Master 直接跑 CI 测试就完了。
|
 |
20
hackape 2021-02-23 13:38:17 +08:00 2
这事儿的本质跟 git 没有任何关系。
即便是不分叉、线性地去开发，想象一下张三开发 A 模块，改了通用服务 C，提交完了，然后李四接着开发 B 模块，然后也改了服务 C 。你看这里面没有分叉再合并、产生冲突的过程，但也不能保证李四改完了的 C 就完全不出问题，除非李四充分理解自己的改动，这包括他需要去看张三的那部分代码。 合并出现冲突，本质上面对的问题还是两个人分别改了同个东西如何保证不出错，要么是李四解决冲突的时候好好读代码，要么把张三叫过来，大家一起 review 一下。 再退一步讲，哪怕只有张三一个人写东西，照样不能保证不出错，相信大家都有过看不懂自己的老代码的经验。 所以说这事儿跟 git 没有半毛钱关系，而你说的问题，别的楼层提到的 CI/CD, TDD 都是有效的方法（如果不流于形式、好好执行的话），然而还是那句话 there's no silver bullet，这个话题没有最终答案的。 |
 |
21
learningman 2021-02-23 13:43:16 +08:00 via Android
配置也不应该放在 git 里吧
|
 |
22
sillydaddy 2021-02-23 13:46:16 +08:00
LZ 提的还是比较明显的合并冲突。肉眼毕竟还可以检查。
更厉害的是，有时合并会**无声无息**地埋下隐藏的炸弹。比如使用 cherry-pick 比如微软的技术文章很详细描述了，“Stop cherry-picking, start merging” (不要使用 cherry-pick，开始使用 merge 吧！) https://devblogs.microsoft.com/oldnewthing/20180312-00/?p=98215 但即使如此，cherry-pick 该用还是用吧，毕竟中招几率很小啊，加上测试就更小啦。 |
 |
23
across 2021-02-23 13:50:12 +08:00
这显然是代码结构问题。模块调用 API 功能不停变，哪个团队受得了。
|
|
24
BeautifulSoap 2021-02-23 14:16:44 +08:00 via Android
@fucUup ？？？？这都想不明白？？？一个 api 修正，其中模型，repository，service，api，swagger 的变更必须拆分成不同的 pr 。你模型，repository，service 这些地方的结构或业务逻辑变了，上面的 api 逻辑没变，单元测试不是有非常大几率失败？这不就是细粒度分太细导致的单元测试失败？
还有 swagger 是根据 api 请求的结构体自动生成的，api 请求的结构体是在 api 辩证的 pr 中被修改。那么请问自动生成的 swagger 文件 diff，是应该和请求结构体的变更一起提交呢，还是单独提交呢？ 细粒度分太细是真的经常出一些问题 |
|
25
sugarkeek OP @yogogo 你这么一说，我想了想，好像看到的项目都是一个开发版本一个分支点。
我现在呢，git 在项目里的实践是看到一些 git 介绍的，说是方便团队协作，每个人一个分支，开发不同模块，最后合并到主线，项目就干好了。基于这个思想，我才采用一个人一个分支的。 @hackape 嗯嗯，there's no silver bullet. @learningman 我是举个例子，就是有可能有交集的地方。有些早期小项目图快，会公用，后面的话我都会注意这个问题。 @sillydaddy 学习了，感觉把主题都升华了。 |
|
26
fucUup 2021-02-23 14:28:54 +08:00
@BeautifulSoap
我们有 40 个微服务, 全球团队 500 人一起开发, 每一次变更都是前后兼容, 不存在你说的问题, 任何 break 代码的提交都会被拒绝, 不应该先重构了一个模块, 再去补写另外一个模块, 这是常识 也就是每一个模块都要保留几个周期的逻辑同时存在, 因为你要考虑你的上下游会回滚, 不这样做的话你就等着上新闻, 像微博公司经常 down 机上热搜 |
|
27
msg7086 2021-02-23 15:12:13 +08:00
@yogogo @sugarkeek
这两个东西原本也不是冲突对立的。 版本需要开分支，是因为会有稳定版和开发版之分。 功能和模块开分支，是因为要多人同时进行开发。 比如你们 1.5 版本发布后，开始开发 1.6 。那么可以先分出 dev-1.6 分支，然后在 1.6 分支上再按照 feature 分出不同的分支。开发完以后先 MR 到 dev-1.6 上，然后等全部测试完了，再 merge 到 master 上，发布上线。 @sillydaddy cherry-picking 和 merging 本质上是差不多的，这和无声无息也没关系，不管有声还是无声，最终都只有测试才能决定合并是否安全。cherry-picking 无错并不代表合并成功。同时这也不应该成为不用 cherry-pick 的理由。 |
|
28
msg7086 2021-02-23 15:16:01 +08:00
@sillydaddy
我又特地看了一下，微软的这篇文章其实也不对，最合理的做法是 rebase 而不是 cherry-pick 或者 merge 。 |
 |
29
remarrexxar 2021-02-23 17:01:42 +08:00
自动化测试跟得上的话，所有要进 master 分支或者其他重要分支的代码都要跑 smoke testing 保证至少不影响主流程，如果功能本身影响主流程测试脚本要同步修改。此外还需要定时跑完整的 regression test 来发现其他可能出现的问题。
|
 |
30
AlynxZhou 2021-02-23 17:11:57 +08:00
diff 本来的含义就是从一个状态到另一个状态有哪些变化嘛，至于这个变化是啥含义它不理解也理解不了，这是工具使用者的任务，不是工具自己的
|
|
31
BeautifulSoap 2021-02-23 17:22:22 +08:00 via Android
@fucUup 老哥建议你再仔细看看我想说的内容，我和你要讲的东西根本不是一回事，你讲的是整体的管理，我讲的是具体到每个服务内代码的修改怎么提 pr
打比方具体来说项目要求给某 api 增加个字段，一般建个 feature/add_field 分支改好代码就行了，但是因为项目要求彻底细分 pr，所以会要求将这一个变更内容拆分成 feature/add_field_change_model，feature/add_field_change_repository，feature/add_field_change_service 等等分支，review 完成之后合并入 feature/add_field 分支，等全部代码都确认没问题后再合并到 master 或者其他环境分支 那么我请问你，feature/add_field_change_model 我改了模型但是上层没有改导致 api 单元测试失败了，我该怎么办？顺便一提因为这些细分的分支只是合并入 feature 分支，所以不会影响环境里跑的服务 |
|
32
sillydaddy 2021-02-23 17:28:16 +08:00
@msg7086 #28，那篇文章我看过但现在已经忘了。rebase 内部就是使用的 cherry-pick 啊。
|
 |
33
nocrush 2021-02-23 17:32:51 +08:00
合并前先 rebase 下目标分支，解决完冲突再 merge
|
|
34
msg7086 2021-02-23 18:03:18 +08:00 via Android
@sillydaddy 方向反了。
应该是让分支 rebase 到主干，你说的那是把主干 pick 到分支。所以我才说不管是 pick （或者你说的那种反向 rebase ）还是 merge 都是不合适的。 rebase 不是基于 cherry pick 。这两个命令本来就都是 commit 的语法糖，没有内部不内部之分。 |
 |
35
est 2021-02-23 18:06:49 +08:00 1
LZ 想要的东西是，两个人同时改一个东西，然后有一个神奇的自动系统或者机制，能让这两人改出来的东西不会有冲突和毛病。。。
|
 |
36
chiu 2021-02-23 23:23:05 +08:00
>> git 能解决代码不同，但是不能保证合并的代码正常运行
这个主要还是看你们组使用 git 开发遵循的 workflow 。如果合并后代码运行出错，那基本是人为的问题，毕竟 resolve conflict 的时候，是人为决定怎么 resolve 的。如果 feature 分支出来自成一支后开发了很多东西，那 rebase 回 master/main 的时候大量 conflicts 在所难免。 |
 |
37
honjow 2021-02-24 00:01:36 +08:00 via iPhone
git 不负责这东西，测试负责
|
 |
38
1OF7G 2021-02-24 00:39:36 +08:00 1
Merge 没有冲突，不代表合并后的代码正确地表达了你的意图，甚至不代表这些代码能够正常执行。
Git 只是帮你追踪代码变动，你自己必须清楚每次 commit 引入了哪些些变动。通常在自己编辑完代码后立即进行 commit , 对引入的变动非常清楚。而 Merge 也是一次引入变动的 commit，但陷阱就是，你可能并不清楚这次 Merge commit 所引入的代码变动。（可能是你很久之前写的 /或者是别人写的）。 从源头上解决问题的方法不是使用各种测试，而是 review 这次 Merge 所引入的变动。本质就是，把 Merge 盲目引入的变动，变成你思考后所认同的变动。下一步，才是各种测试。 |
 |
39
eastphoton 2021-02-24 16:35:20 +08:00
git 管合并，不管运行。。。
rebase 翻译看到过的最无语的是 变基。。 |
Select Language