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 翻译看到过的最无语的是 变基。。 |