作者pttdocc (Hi)
看板Soft_Job
标题[请益] 请问这样的git使用方式是否是正确的?
时间Thu Oct 20 23:38:50 2022
请问一下，本人是程式新手，最近加入了一个组织，里面的开发团队的git使用方法，让
我觉得有点怪怪的，但是我也觉得这也可能是正确的git使用方式，只是我以前不知道而
已，所以想请问一下，以下的git使用方式，是否很常见? 是否是合理的?
假如某个repo里有3个folder - serviceA, serviceB, serviceC，这3个folder在开发阶
段不会有dependency，这个开发团队的作法是，从master branch一开始的init commit
里，分出3个branch A, B, C，再从这3个branch分别建立出上面的3个folder，当要修改
任何一个service时， 就从对应的branch create出新的branch，改好後再merge回
serviceX的branch, 再merge回master branch。
这样的作法总是让我觉得怪怪的，至少如果有人不知情而直接从master branch分出
NEW branch去修改serviceA，那就无法再直接从NEW branch 或master branch merge
回branch A，因为NEW branch 和master branch 都包含了folder serviceA, serviceB,
serviceC, 而branch A, B, C照开发团队的作法，是要维持各自只有对应的serviceX
folder的。
所以想请问这是否是种常见的git使用方式? 是否合理? 谢谢。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.141.57.213 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1666280332.A.5AE.html
1F：推 gasbomb: git就跟打麻将一样 一开始大家规则讲好就好了 10/20 23:40
2F：→ BlueBird5566: git就跟一夜情一样 一开始大家规则讲好就好了 10/20 23:43
3F：→ pttdocc: 但我觉得如果是有缺陷的规则，就算讲好了一样会有缺陷 10/20 23:44
4F：推 mercurycgt68: 你不是老鸟就只能吞了 不要跟薪水烤鸡过不去 10/20 23:46
5F：→ BlueBird5566: 直接问资深同事为什麽这样弄不是比较快？ 10/20 23:48
6F：→ BlueBird5566: 很多东西都有历史包袱的 公司外的人也不会知道 10/20 23:48
7F：推 eeyellow: 你们需要的是branch policy跟PR review 10/20 23:55
8F：→ hduek153: git有n个团队有n种用法 真的 不要怀疑 10/21 00:04
※ 编辑: pttdocc (220.141.57.213 台湾), 10/21/2022 00:21:56
9F：推 viper9709: 二楼XD 10/21 00:25
10F：推 libitum: 有时外行真的很难了解这样发展的原因 所以没有什麽是绝对 10/21 00:25
11F：→ libitum: 合理 10/21 00:25
12F：→ pttdocc: 我想我上面说的应该就是一种branch policy了, 这样作的 10/21 00:27
13F：→ pttdocc: 另一个不算大的问题是 从A, B, C间切换会花更多时间 10/21 00:27
14F：→ t64141: 你可以先问为什麽这样做，是为了避免什麽问题得到什麽好 10/21 00:30
15F：→ t64141: 处，再回来看这样做是否有效，或有没有其他更简单的策略 10/21 00:30
16F：→ t64141: 可以达到相同效果 10/21 00:30
17F：→ t64141: 好奇这样做的话如果 service 之间产生依赖的话分支怎麽切 10/21 00:31
18F：→ dog30111: 没有正确只有适不适合 有觉得更适合的作法就跟团队讨论 10/21 00:32
19F：→ dog30111: 吧... 10/21 00:32
20F：→ pttdocc: 如上述, service之间在开发阶段没有dependency, 如果有 10/21 00:33
21F：→ pttdocc: 的话,例如IDE要同时开2个folder下的Project的话，就很 10/21 00:34
22F：→ pttdocc: 明显不能这样 10/21 00:35
23F：推 ql4au04: 如果遵守这个规则 就不会有一开始就从master branch切出 10/21 00:47
24F：→ ql4au04: 去做A service吧 10/21 00:47
why?
25F：→ ql4au04: 直觉想就是要把每个team切很开 不要有任何相依性 可能是 10/21 00:50
26F：→ ql4au04: 担心改code还要跨team sync很麻烦 10/21 00:50
※ 编辑: pttdocc (220.141.57.213 台湾), 10/21/2022 00:51:23
27F：推 ql4au04: 因为要碰你们codebase的人 本身就要和对应的人sync完吧？ 10/21 00:55
28F：→ ql4au04: 还是你们会有个情况是完全不知道你们开发流程的人跑来上 10/21 00:55
29F：→ ql4au04: code? 但那样code review应该不会过吧 10/21 00:55
30F：→ pttdocc: 会有的，code也merge进去了，不便多说 10/21 01:03
31F：推 ql4au04: 神奇XDD 那後续是用spare checkout去sync吗？ 还是就只能 10/21 01:13
32F：→ ql4au04: 摆着XD 10/21 01:13
33F：→ ql4au04: * sparse 10/21 01:13
34F：→ gocreating: 推测这麽做可以让ci cd pipeline比较好管理 10/21 01:27
35F：→ pttdocc: 後续应该是原branch还没其它更动时就直接git check 特定 10/21 01:45
36F：→ pttdocc: folder整个盖回去吧 或状况还不乱时cherry-pick应该也 10/21 01:46
37F：→ pttdocc: 可以 git sparse印象中是git 古早是不可能只merge部份 10/21 01:47
38F：推 abccbaandy: 你直接问同事不就知道了... 10/21 01:48
39F：→ pttdocc: file的 但这个command出来後好像可以(不熟悉它所以不确定 10/21 01:48
40F：→ pttdocc: 其实有大约问了几个人，得到的答案也是不确定的说法，也 10/21 01:53
41F：→ pttdocc: 不便多说，以上 10/21 01:53
42F：推 j9d9: rebase 10/21 07:45
43F：→ MarcoReus: 感觉比较适合拆成三个repo再用submodule合成一个 10/21 07:56
44F：推 wulouise: 还好吧，你说切换不方便的问题怎麽不用git worktree 10/21 08:17
45F：推 Lhmstu: 没有对错，有可能是历史或是管理原因才这样做，git 事先 10/21 08:17
46F：→ Lhmstu: 讲好怎麽用就好。不过你们公司这样用，八成是希望未来A,B 10/21 08:17
47F：→ Lhmstu: ,C能够成为单独的产品线赚钱 10/21 08:17
48F：推 vi000246: 可能是一开始init的人懒 10/21 09:02
49F：→ longlongint: 每个修改都切branch 不是很棒吗 10/21 09:35
50F：→ longlongint: 你没看过commits 一整坨夹板夹到眼神死的团队 10/21 09:35
51F：→ longlongint: 老板还说自动测试跟版控会拖慢进度 没有必要（？ 10/21 09:36
52F：→ longlongint: 你们团队的问题在 没有开ABC三个repo 10/21 09:38
53F：推 lovdkkkk: 有外部的人共同开发吗？有的话可能是要省人头费 10/21 09:47
54F：→ lovdkkkk: 记得是不同专案分开收费的 一个人加两个专案就要收两笔 10/21 09:48
55F：→ leolarrel: 这对楼主是一个很好的学习机会.楼主可以查 "git flow" 10/21 11:22
56F：推 BlacksPig: 在问Google跟Meta在用的Monorepo? 10/21 11:37
57F：推 monkai: 省repo 的钱吧 10/21 12:49
58F：推 abc0922001: 你应该拿着一瓶上好的酒与酒杯，坐在椅子上听老鸟讲 10/21 13:45
59F：→ abc0922001: 有关於这个 repo 的历史 10/21 13:45
60F：→ abc0922001: 你自己也分三个资料夹，分别放 A、B、C 三个分支 10/21 13:46
61F：嘘 B0988698088: 去问老鸟我们无法通灵 不合理你也管不着 安静办事就 10/21 14:07
62F：→ B0988698088: 好 10/21 14:07
63F：→ quickbym1: 干嘛不开3个 repo 既然没有相依性 10/21 15:03
64F：→ DrTech: git是死的，人是活的。 10/21 17:20
65F：→ DrTech: 这种专案管理的方式与git本身技术与gir规范无关了，而是要 10/21 17:23
66F：→ DrTech: 问你们组织，为什麽专案程式码要这样管理。 10/21 17:23
67F：推 Mupzopod: 如果有大量CICD的话、分开来PR比较方便管理 10/21 18:52
68F：→ dong531: 那你说用手抓饭吃是对的还是用筷子吃饭是对的？又或是用 10/21 19:01
69F：→ dong531: 刀叉吃饭才是对的呢？ 10/21 19:01
70F：推 kurtsgm: 我不敢说对错 但如果是我的话不会这样干 10/21 22:50
71F：→ jj2564: A rebase onto master就可以了吧? 晚点我试一下 10/21 23:44
72F：→ jj2564: 哈不行，这样就只能cherry pick了 10/22 00:01
74F：推 BigCockman: 看起来还好啊 问题在哪 10/22 01:43
75F：推 Segundus: 不会说有对错，但绝不这麽做。要麽拆成三个repo，要嘛 10/22 10:19
76F：→ Segundus: 就都在master 10/22 10:19
77F：→ peter98: 我是比较喜欢在branch上面又长出branch 当然 如果是个人 10/22 15:46
78F：→ peter98: 自己的branch就无所谓 自己的branch想怎麽完就怎麽玩 10/22 15:46
79F：→ peter98: 但你的例子branch A/B/C似乎是有多人在用 不建议在长出 10/22 15:47
80F：→ peter98: branch 一段时间後会乱到无法无天 10/22 15:47
81F：→ peter98: 另外 如果是不同的service 这样最好code repo各自独立 10/22 15:48
82F：→ peter98: 第一个推文是不喜欢 打错了 10/22 16:24
83F：推 roccqqck: 追求正确是无意义的 你该说服他们的是有没有比较「方便 10/22 17:25
84F：→ roccqqck: 」 10/22 17:25
85F：→ roccqqck: 有没有什麽痛点他们可以改个git方式就处理掉 10/22 17:25
86F：推 lej: git 就是这样，规则讲好，code review/branch policy弄好，大 10/23 13:21
87F：→ lej: 家跟着就行了。你在那边不便多说，是要大家通灵喔 10/23 13:21
88F：推 acgotaku: 通常devops or platform eng 是菜鸟或不太懂怎麽分切环 10/24 10:10
89F：→ acgotaku: 境,就会弄一个很困惑的git flow让 sde先挡一阵子,但用一 10/24 10:11
90F：→ acgotaku: 阵子服务上线後,又没有胆子去重写又没人会,就会变成这样 10/24 10:12
91F：→ acgotaku: 而且我建议,不要在主专案下乱开branch,在 fork 出来的 10/24 10:15
92F：→ acgotaku: repo开feature branch,都改好後再发MR,这样你改其他服务 10/24 10:17
93F：→ acgotaku: 主干道的commit history也能看得一清二楚 10/24 10:18
94F：推 jovilu: 如果管repo的人是不同单位，开repo要填申请单还要层层审 10/27 17:18
95F：→ jovilu: 核。人员调动要改权限，三个repo要填三张单，就不难理解 10/27 17:18
96F：→ jovilu: 为什麽一个repo当三个用 10/27 17:18
97F：推 expury: 乾脆连办公桌椅都自备好了 我猜原本是想搞像 FB 那样 mon 10/28 20:52
98F：→ expury: o repo 10/28 20:52
99F：→ expury: 期待不同 team 的工程师彼此随时可以 support switch pro 10/28 20:53
100F：→ expury: ject 10/28 20:53
101F：→ KJZ5223: monorepo? 11/02 12:59