楼主:
pttdocc (Hi)
2022-10-21 07:38:50请问一下，本人是程式新手，最近加入了一个组织，里面的开发团队的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使用方式? 是否合理? 谢谢。
作者:
gasbomb (虚空雷神兽)
2022-10-21 07:40:00git就跟打麻将一样 一开始大家规则讲好就好了
楼主:
pttdocc (Hi)
2022-10-21 07:44:00但我觉得如果是有缺陷的规则，就算讲好了一样会有缺陷
作者: mercurycgt68 (发芽的吉它手) 2022-10-21 07:46:00
你不是老鸟就只能吞了 不要跟薪水烤鸡过不去
直接问资深同事为什么这样弄不是比较快？很多东西都有历史包袱的 公司外的人也不会知道
作者:
eeyellow (TWC英勇长存人心)
2022-10-21 07:55:00你们需要的是branch policy跟PR review
作者:
hduek153 (专业打酱油)
2022-10-21 08:04:00git有n个团队有n种用法 真的 不要怀疑
作者:
libitum (libitum)
2022-10-21 08:25:00有时外行真的很难了解这样发展的原因 所以没有什么是绝对合理
楼主:
pttdocc (Hi)
2022-10-21 08:27:00我想我上面说的应该就是一种branch policy了, 这样作的另一个不算大的问题是 从A, B, C间切换会花更多时间
作者: t64141 (榕树) 2022-10-21 08:30:00
你可以先问为什么这样做，是为了避免什么问题得到什么好处，再回来看这样做是否有效，或有没有其他更简单的策略可以达到相同效果好奇这样做的话如果 service 之间产生依赖的话分支怎么切
作者: dog30111 (安) 2022-10-21 08:32:00
没有正确只有适不适合 有觉得更适合的作法就跟团队讨论吧...
楼主:
pttdocc (Hi)
2022-10-21 08:33:00如上述, service之间在开发阶段没有dependency, 如果有的话,例如IDE要同时开2个folder下的Project的话，就很明显不能这样
作者:
ql4au04 (方便面)
2022-10-21 08:47:00如果遵守这个规则 就不会有一开始就从master branch切出去做A service吧直觉想就是要把每个team切很开 不要有任何相依性 可能是担心改code还要跨team sync很麻烦因为要碰你们codebase的人 本身就要和对应的人sync完吧？还是你们会有个情况是完全不知道你们开发流程的人跑来上code? 但那样code review应该不会过吧
楼主:
pttdocc (Hi)
2022-10-21 09:03:00会有的，code也merge进去了，不便多说
作者:
ql4au04 (方便面)
2022-10-21 09:13:00神奇XDD 那后续是用spare checkout去sync吗？ 还是就只能摆着XD* sparse
推测这么做可以让ci cd pipeline比较好管理
楼主:
pttdocc (Hi)
2022-10-21 09:45:00后续应该是原branch还没其它更动时就直接git check 特定folder整个盖回去吧 或状况还不乱时cherry-pick应该也可以 git sparse印象中是git 古早是不可能只merge部份
楼主:
pttdocc (Hi)
2022-10-21 09:48:00file的 但这个command出来后好像可以(不熟悉它所以不确定其实有大约问了几个人，得到的答案也是不确定的说法，也不便多说，以上
作者: j9d9 (Vicinaty) 2022-10-21 15:45:00
rebase
作者:
MarcoReus (Marco Reus)
2022-10-21 15:56:00感觉比较适合拆成三个repo再用submodule合成一个
作者:
wulouise (在线上!=在电脑前)
2022-10-21 16:17:00还好吧，你说切换不方便的问题怎么不用git worktree
作者:
Lhmstu (lhmstu)
2022-10-21 16:17:00没有对错，有可能是历史或是管理原因才这样做，git 事先讲好怎么用就好。不过你们公司这样用，八成是希望未来A,B,C能够成为单独的产品线赚钱
作者: longlongint (华哥尔) 2022-10-21 17:35:00
每个修改都切branch 不是很棒吗你没看过commits 一整坨夹板夹到眼神死的团队老板还说自动测试跟版控会拖慢进度 没有必要（？你们团队的问题在 没有开ABC三个repo
有外部的人共同开发吗？有的话可能是要省人头费记得是不同专案分开收费的 一个人加两个专案就要收两笔
这对楼主是一个很好的学习机会.楼主可以查 "git flow"
作者:
BlacksPig (Black Handsome s Pig)
2022-10-21 19:37:00在问Google跟Meta在用的Monorepo?
作者:
gasbomb (虚空雷神兽)
2022-10-20 23:40:00git就跟打麻将一样 一开始大家规则讲好就好了
楼主:
pttdocc (Hi)
2022-10-20 23:44:00但我觉得如果是有缺陷的规则，就算讲好了一样会有缺陷
作者: mercurycgt68 (发芽的吉它手) 2022-10-20 23:46:00
你不是老鸟就只能吞了 不要跟薪水烤鸡过不去
直接问资深同事为什么这样弄不是比较快？很多东西都有历史包袱的 公司外的人也不会知道
作者:
eeyellow (TWC英勇长存人心)
2022-10-20 23:55:00你们需要的是branch policy跟PR review
作者:
hduek153 (专业打酱油)
2022-10-21 00:04:00git有n个团队有n种用法 真的 不要怀疑
作者:
libitum (libitum)
2022-10-21 00:25:00有时外行真的很难了解这样发展的原因 所以没有什么是绝对合理
楼主:
pttdocc (Hi)
2022-10-21 00:27:00我想我上面说的应该就是一种branch policy了, 这样作的另一个不算大的问题是 从A, B, C间切换会花更多时间
作者: t64141 (榕树) 2022-10-21 00:30:00
你可以先问为什么这样做，是为了避免什么问题得到什么好处，再回来看这样做是否有效，或有没有其他更简单的策略可以达到相同效果好奇这样做的话如果 service 之间产生依赖的话分支怎么切
作者: dog30111 (安) 2022-10-21 00:32:00
没有正确只有适不适合 有觉得更适合的作法就跟团队讨论吧...
楼主:
pttdocc (Hi)
2022-10-21 00:33:00如上述, service之间在开发阶段没有dependency, 如果有的话,例如IDE要同时开2个folder下的Project的话，就很明显不能这样
作者:
ql4au04 (方便面)
2022-10-21 00:47:00如果遵守这个规则 就不会有一开始就从master branch切出去做A service吧直觉想就是要把每个team切很开 不要有任何相依性 可能是担心改code还要跨team sync很麻烦因为要碰你们codebase的人 本身就要和对应的人sync完吧？还是你们会有个情况是完全不知道你们开发流程的人跑来上code? 但那样code review应该不会过吧
楼主:
pttdocc (Hi)
2022-10-21 01:03:00会有的，code也merge进去了，不便多说
作者:
ql4au04 (方便面)
2022-10-21 01:13:00神奇XDD 那后续是用spare checkout去sync吗？ 还是就只能摆着XD* sparse
推测这么做可以让ci cd pipeline比较好管理
楼主:
pttdocc (Hi)
2022-10-21 01:45:00后续应该是原branch还没其它更动时就直接git check 特定folder整个盖回去吧 或状况还不乱时cherry-pick应该也可以 git sparse印象中是git 古早是不可能只merge部份
楼主:
pttdocc (Hi)
2022-10-21 01:48:00file的 但这个command出来后好像可以(不熟悉它所以不确定其实有大约问了几个人，得到的答案也是不确定的说法，也不便多说，以上
作者: j9d9 (Vicinaty) 2022-10-21 07:45:00
rebase
作者:
MarcoReus (Marco Reus)
2022-10-21 07:56:00感觉比较适合拆成三个repo再用submodule合成一个
作者:
wulouise (在线上!=在电脑前)
2022-10-21 08:17:00还好吧，你说切换不方便的问题怎么不用git worktree
作者:
Lhmstu (lhmstu)
2022-10-21 08:17:00没有对错，有可能是历史或是管理原因才这样做，git 事先讲好怎么用就好。不过你们公司这样用，八成是希望未来A,B,C能够成为单独的产品线赚钱
作者: longlongint (华哥尔) 2022-10-21 09:35:00
每个修改都切branch 不是很棒吗你没看过commits 一整坨夹板夹到眼神死的团队老板还说自动测试跟版控会拖慢进度 没有必要（？你们团队的问题在 没有开ABC三个repo
有外部的人共同开发吗？有的话可能是要省人头费记得是不同专案分开收费的 一个人加两个专案就要收两笔
这对楼主是一个很好的学习机会.楼主可以查 "git flow"
作者:
BlacksPig (Black Handsome s Pig)
2022-10-21 11:37:00在问Google跟Meta在用的Monorepo?
作者:
monkai (monkai)
2022-10-21 12:49:00省repo 的钱吧
你应该拿着一瓶上好的酒与酒杯，坐在椅子上听老鸟讲有关于这个 repo 的历史你自己也分三个资料夹，分别放 A、B、C 三个分支
去问老鸟我们无法通灵 不合理你也管不着 安静办事就好
作者: quickbym1 (张探长) 2022-10-21 15:03:00
干嘛不开3个 repo 既然没有相依性
作者:
monkai (monkai)
2022-10-21 20:49:00省repo 的钱吧
你应该拿着一瓶上好的酒与酒杯，坐在椅子上听老鸟讲有关于这个 repo 的历史你自己也分三个资料夹，分别放 A、B、C 三个分支
去问老鸟我们无法通灵 不合理你也管不着 安静办事就好
作者: quickbym1 (张探长) 2022-10-21 23:03:00
干嘛不开3个 repo 既然没有相依性
作者:
DrTech (竹科管理处网军研发人员)
2022-10-21 17:20:00git是死的，人是活的。这种专案管理的方式与git本身技术与gir规范无关了，而是要问你们组织，为什么专案程式码要这样管理。
作者:
Mupzopod (pinballmachine)
2022-10-21 18:52:00如果有大量CICD的话、分开来PR比较方便管理
作者:
dong531 (猫王)
2022-10-21 19:01:00那你说用手抓饭吃是对的还是用筷子吃饭是对的？又或是用刀叉吃饭才是对的呢？
不会说有对错，但绝不这么做。要么拆成三个repo，要嘛就都在master
作者:
peter98 (新兵)
2022-10-22 15:46:00我是比较喜欢在branch上面又长出branch 当然 如果是个人自己的branch就无所谓 自己的branch想怎么完就怎么玩但你的例子branch A/B/C似乎是有多人在用 不建议在长出branch 一段时间后会乱到无法无天另外 如果是不同的service 这样最好code repo各自独立第一个推文是不喜欢 打错了
作者: roccqqck (ccqq) 2022-10-22 17:25:00
追求正确是无意义的 你该说服他们的是有没有比较“方便”有没有什么痛点他们可以改个git方式就处理掉
作者:
lej (认真就输了XD)
2022-10-23 13:21:00git 就是这样，规则讲好，code review/branch policy弄好，大家跟着就行了。你在那边不便多说，是要大家通灵喔
作者:
acgotaku (otaku)
2022-10-24 10:10:00通常devops or platform eng 是菜鸟或不太懂怎么分切环境,就会弄一个很困惑的git flow让 sde先挡一阵子,但用一阵子服务上线后,又没有胆子去重写又没人会,就会变成这样而且我建议,不要在主专案下乱开branch,在 fork 出来的repo开feature branch,都改好后再发MR,这样你改其他服务主干道的commit history也能看得一清二楚
作者: jovilu (....) 2022-10-27 17:18:00
如果管repo的人是不同单位，开repo要填申请单还要层层审核。人员调动要改权限，三个repo要填三张单，就不难理解为什么一个repo当三个用
作者:
expury (ao6x87)
2022-10-28 20:52:00干脆连办公桌椅都自备好了 我猜原本是想搞像 FB 那样 mono repo期待不同 team 的工程师彼此随时可以 support switch project
作者:
KJZ5223 (密斯特博克)
2022-11-02 12:59:00monorepo?