推 gasbomb: git就跟打麻將一樣 一開始大家規則講好就好了 10/20 23:40
→ BlueBird5566: git就跟一夜情一樣 一開始大家規則講好就好了 10/20 23:43
→ pttdocc: 但我覺得如果是有缺陷的規則,就算講好了一樣會有缺陷 10/20 23:44
推 mercurycgt68: 你不是老鳥就只能吞了 不要跟薪水烤雞過不去 10/20 23:46
→ BlueBird5566: 直接問資深同事為什麼這樣弄不是比較快? 10/20 23:48
→ BlueBird5566: 很多東西都有歷史包袱的 公司外的人也不會知道 10/20 23:48
推 eeyellow: 你們需要的是branch policy跟PR review 10/20 23:55
→ hduek153: git有n個團隊有n種用法 真的 不要懷疑 10/21 00:04
推 viper9709: 二樓XD 10/21 00:25
推 libitum: 有時外行真的很難了解這樣發展的原因 所以沒有什麼是絕對 10/21 00:25
→ libitum: 合理 10/21 00:25
→ pttdocc: 我想我上面說的應該就是一種branch policy了, 這樣作的 10/21 00:27
→ pttdocc: 另一個不算大的問題是 從A, B, C間切換會花更多時間 10/21 00:27
→ t64141: 你可以先問為什麼這樣做,是為了避免什麼問題得到什麼好 10/21 00:30
→ t64141: 處,再回來看這樣做是否有效,或有沒有其他更簡單的策略 10/21 00:30
→ t64141: 可以達到相同效果 10/21 00:30
→ t64141: 好奇這樣做的話如果 service 之間產生依賴的話分支怎麼切 10/21 00:31
→ dog30111: 沒有正確只有適不適合 有覺得更適合的作法就跟團隊討論 10/21 00:32
→ dog30111: 吧... 10/21 00:32
→ pttdocc: 如上述, service之間在開發階段沒有dependency, 如果有 10/21 00:33
→ pttdocc: 的話,例如IDE要同時開2個folder下的Project的話,就很 10/21 00:34
→ pttdocc: 明顯不能這樣 10/21 00:35
推 ql4au04: 如果遵守這個規則 就不會有一開始就從master branch切出 10/21 00:47
→ ql4au04: 去做A service吧 10/21 00:47
→ ql4au04: 直覺想就是要把每個team切很開 不要有任何相依性 可能是 10/21 00:50
→ ql4au04: 擔心改code還要跨team sync很麻煩 10/21 00:50
推 ql4au04: 因為要碰你們codebase的人 本身就要和對應的人sync完吧? 10/21 00:55
→ ql4au04: 還是你們會有個情況是完全不知道你們開發流程的人跑來上 10/21 00:55
→ ql4au04: code? 但那樣code review應該不會過吧 10/21 00:55
→ pttdocc: 會有的,code也merge進去了,不便多說 10/21 01:03
推 ql4au04: 神奇XDD 那後續是用spare checkout去sync嗎? 還是就只能 10/21 01:13
→ ql4au04: 擺著XD 10/21 01:13
→ ql4au04: * sparse 10/21 01:13
→ gocreating: 推測這麼做可以讓ci cd pipeline比較好管理 10/21 01:27
→ pttdocc: 後續應該是原branch還沒其它更動時就直接git check 特定 10/21 01:45
→ pttdocc: folder整個蓋回去吧 或狀況還不亂時cherry-pick應該也 10/21 01:46
→ pttdocc: 可以 git sparse印象中是git 古早是不可能只merge部份 10/21 01:47
推 abccbaandy: 你直接問同事不就知道了... 10/21 01:48
→ pttdocc: file的 但這個command出來後好像可以(不熟悉它所以不確定 10/21 01:48
→ pttdocc: 其實有大約問了幾個人,得到的答案也是不確定的說法,也 10/21 01:53
→ pttdocc: 不便多說,以上 10/21 01:53
推 j9d9: rebase 10/21 07:45
→ MarcoReus: 感覺比較適合拆成三個repo再用submodule合成一個 10/21 07:56
推 wulouise: 還好吧,你說切換不方便的問題怎麼不用git worktree 10/21 08:17
推 Lhmstu: 沒有對錯,有可能是歷史或是管理原因才這樣做,git 事先 10/21 08:17
→ Lhmstu: 講好怎麼用就好。不過你們公司這樣用,八成是希望未來A,B 10/21 08:17
→ Lhmstu: ,C能夠成為單獨的產品線賺錢 10/21 08:17
推 vi000246: 可能是一開始init的人懶 10/21 09:02
→ longlongint: 每個修改都切branch 不是很棒嗎 10/21 09:35
→ longlongint: 你沒看過commits 一整坨夾板夾到眼神死的團隊 10/21 09:35
→ longlongint: 老闆還說自動測試跟版控會拖慢進度 沒有必要(? 10/21 09:36
→ longlongint: 你們團隊的問題在 沒有開ABC三個repo 10/21 09:38
推 lovdkkkk: 有外部的人共同開發嗎?有的話可能是要省人頭費 10/21 09:47
→ lovdkkkk: 記得是不同專案分開收費的 一個人加兩個專案就要收兩筆 10/21 09:48
→ leolarrel: 這對樓主是一個很好的學習機會.樓主可以查 "git flow" 10/21 11:22
推 BlacksPig: 在問Google跟Meta在用的Monorepo? 10/21 11:37
推 monkai: 省repo 的錢吧 10/21 12:49
推 abc0922001: 你應該拿著一瓶上好的酒與酒杯,坐在椅子上聽老鳥講 10/21 13:45
→ abc0922001: 有關於這個 repo 的歷史 10/21 13:45
→ abc0922001: 你自己也分三個資料夾,分別放 A、B、C 三個分支 10/21 13:46
噓 B0988698088: 去問老鳥我們無法通靈 不合理你也管不着 安靜辦事就 10/21 14:07
→ B0988698088: 好 10/21 14:07
→ quickbym1: 幹嘛不開3個 repo 既然沒有相依性 10/21 15:03
→ DrTech: git是死的,人是活的。 10/21 17:20
→ DrTech: 這種專案管理的方式與git本身技術與gir規範無關了,而是要 10/21 17:23
→ DrTech: 問你們組織,為什麼專案程式碼要這樣管理。 10/21 17:23
推 Mupzopod: 如果有大量CICD的話、分開來PR比較方便管理 10/21 18:52
→ dong531: 那你說用手抓飯吃是對的還是用筷子吃飯是對的?又或是用 10/21 19:01
→ dong531: 刀叉吃飯才是對的呢? 10/21 19:01
推 kurtsgm: 我不敢說對錯 但如果是我的話不會這樣幹 10/21 22:50
→ jj2564: A rebase onto master就可以了吧? 晚點我試一下 10/21 23:44
→ jj2564: 哈不行,這樣就只能cherry pick了 10/22 00:01
推 BigCockman: 看起來還好啊 問題在哪 10/22 01:43
推 Segundus: 不會說有對錯,但絕不這麼做。要麼拆成三個repo,要嘛 10/22 10:19
→ Segundus: 就都在master 10/22 10:19
→ peter98: 我是比較喜歡在branch上面又長出branch 當然 如果是個人 10/22 15:46
→ peter98: 自己的branch就無所謂 自己的branch想怎麼完就怎麼玩 10/22 15:46
→ peter98: 但你的例子branch A/B/C似乎是有多人在用 不建議在長出 10/22 15:47
→ peter98: branch 一段時間後會亂到無法無天 10/22 15:47
→ peter98: 另外 如果是不同的service 這樣最好code repo各自獨立 10/22 15:48
→ peter98: 第一個推文是不喜歡 打錯了 10/22 16:24
推 roccqqck: 追求正確是無意義的 你該說服他們的是有沒有比較「方便 10/22 17:25
→ roccqqck: 」 10/22 17:25
→ roccqqck: 有沒有什麼痛點他們可以改個git方式就處理掉 10/22 17:25
推 lej: git 就是這樣,規則講好,code review/branch policy弄好,大 10/23 13:21
→ lej: 家跟著就行了。你在那邊不便多說,是要大家通靈喔 10/23 13:21
推 acgotaku: 通常devops or platform eng 是菜鳥或不太懂怎麼分切環 10/24 10:10
→ acgotaku: 境,就會弄一個很困惑的git flow讓 sde先擋一陣子,但用一 10/24 10:11
→ acgotaku: 陣子服務上線後,又沒有膽子去重寫又沒人會,就會變成這樣 10/24 10:12
→ acgotaku: 而且我建議,不要在主專案下亂開branch,在 fork 出來的 10/24 10:15
→ acgotaku: repo開feature branch,都改好後再發MR,這樣你改其他服務 10/24 10:17
→ acgotaku: 主幹道的commit history也能看得一清二楚 10/24 10:18
推 jovilu: 如果管repo的人是不同單位,開repo要填申請單還要層層審 10/27 17:18
→ jovilu: 核。人員調動要改權限,三個repo要填三張單,就不難理解 10/27 17:18
→ jovilu: 為什麼一個repo當三個用 10/27 17:18
推 expury: 乾脆連辦公桌椅都自備好了 我猜原本是想搞像 FB 那樣 mon 10/28 20:52
→ expury: o repo 10/28 20:52
→ expury: 期待不同 team 的工程師彼此隨時可以 support switch pro 10/28 20:53
→ expury: ject 10/28 20:53
→ KJZ5223: monorepo? 11/02 12:59