PTT職涯區 / Soft_Job (軟體人)

[請益] 請問這樣的git使用方式是否是正確的?

看板Soft_Job (軟體人)作者 (Hi)時間3年前 (2022/10/20 23:38), 3年前編輯推噓25(26推 1噓 74→)
留言101則, 40人參與, 最新討論串1/2 (看更多)
請問一下，本人是程式新手，最近加入了一個組織，裡面的開發團隊的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://www.ptt.cc/bbs/Soft_Job/M.1666280332.A.5AE.html
推
10/20 23:40, 3年前 , 1F
git就跟打麻將一樣 一開始大家規則講好就好了
10/20 23:40, 1F
→
10/20 23:43, 3年前 , 2F
git就跟一夜情一樣 一開始大家規則講好就好了
10/20 23:43, 2F
→
10/20 23:44, 3年前 , 3F
但我覺得如果是有缺陷的規則，就算講好了一樣會有缺陷
10/20 23:44, 3F
推
10/20 23:46, 3年前 , 4F
你不是老鳥就只能吞了 不要跟薪水烤雞過不去
10/20 23:46, 4F
→
10/20 23:48, 3年前 , 5F
直接問資深同事為什麼這樣弄不是比較快？
10/20 23:48, 5F
→
10/20 23:48, 3年前 , 6F
很多東西都有歷史包袱的 公司外的人也不會知道
10/20 23:48, 6F
推
10/20 23:55, 3年前 , 7F
你們需要的是branch policy跟PR review
10/20 23:55, 7F
→
10/21 00:04, 3年前 , 8F
git有n個團隊有n種用法 真的 不要懷疑
10/21 00:04, 8F
※ 編輯: pttdocc (220.141.57.213 臺灣), 10/21/2022 00:21:56
推
10/21 00:25, 3年前 , 9F
二樓XD
10/21 00:25, 9F
推
10/21 00:25, 3年前 , 10F
有時外行真的很難了解這樣發展的原因 所以沒有什麼是絕對
10/21 00:25, 10F
→
10/21 00:25, 3年前 , 11F
合理
10/21 00:25, 11F
→
10/21 00:27, 3年前 , 12F
我想我上面說的應該就是一種branch policy了, 這樣作的
10/21 00:27, 12F
→
10/21 00:27, 3年前 , 13F
另一個不算大的問題是 從A, B, C間切換會花更多時間
10/21 00:27, 13F
→
10/21 00:30, 3年前 , 14F
你可以先問為什麼這樣做，是為了避免什麼問題得到什麼好
10/21 00:30, 14F
→
10/21 00:30, 3年前 , 15F
處，再回來看這樣做是否有效，或有沒有其他更簡單的策略
10/21 00:30, 15F
→
10/21 00:30, 3年前 , 16F
可以達到相同效果
10/21 00:30, 16F
→
10/21 00:31, 3年前 , 17F
好奇這樣做的話如果 service 之間產生依賴的話分支怎麼切
10/21 00:31, 17F
→
10/21 00:32, 3年前 , 18F
沒有正確只有適不適合 有覺得更適合的作法就跟團隊討論
10/21 00:32, 18F
→
10/21 00:32, 3年前 , 19F
吧...
10/21 00:32, 19F
→
10/21 00:33, 3年前 , 20F
如上述, service之間在開發階段沒有dependency, 如果有
10/21 00:33, 20F
→
10/21 00:34, 3年前 , 21F
的話,例如IDE要同時開2個folder下的Project的話，就很
10/21 00:34, 21F
→
10/21 00:35, 3年前 , 22F
明顯不能這樣
10/21 00:35, 22F
推
10/21 00:47, 3年前 , 23F
如果遵守這個規則 就不會有一開始就從master branch切出
10/21 00:47, 23F
→
10/21 00:47, 3年前 , 24F
去做A service吧
10/21 00:47, 24F
why?
→
10/21 00:50, 3年前 , 25F
直覺想就是要把每個team切很開 不要有任何相依性 可能是
10/21 00:50, 25F
→
10/21 00:50, 3年前 , 26F
擔心改code還要跨team sync很麻煩
10/21 00:50, 26F
※ 編輯: pttdocc (220.141.57.213 臺灣), 10/21/2022 00:51:23
推
10/21 00:55, 3年前 , 27F
因為要碰你們codebase的人 本身就要和對應的人sync完吧？
10/21 00:55, 27F
→
10/21 00:55, 3年前 , 28F
還是你們會有個情況是完全不知道你們開發流程的人跑來上
10/21 00:55, 28F
→
10/21 00:55, 3年前 , 29F
code? 但那樣code review應該不會過吧
10/21 00:55, 29F
→
10/21 01:03, 3年前 , 30F
會有的，code也merge進去了，不便多說
10/21 01:03, 30F
推
10/21 01:13, 3年前 , 31F
神奇XDD 那後續是用spare checkout去sync嗎？ 還是就只能
10/21 01:13, 31F
→
10/21 01:13, 3年前 , 32F
擺著XD
10/21 01:13, 32F
→
10/21 01:13, 3年前 , 33F
* sparse
10/21 01:13, 33F
→
10/21 01:27, 3年前 , 34F
推測這麼做可以讓ci cd pipeline比較好管理
10/21 01:27, 34F
→
10/21 01:45, 3年前 , 35F
後續應該是原branch還沒其它更動時就直接git check 特定
10/21 01:45, 35F
→
10/21 01:46, 3年前 , 36F
folder整個蓋回去吧 或狀況還不亂時cherry-pick應該也
10/21 01:46, 36F
還有 25 則推文
→
10/21 14:07, 3年前 , 62F
好
10/21 14:07, 62F
→
10/21 15:03, 3年前 , 63F
幹嘛不開3個 repo 既然沒有相依性
10/21 15:03, 63F
→
10/21 17:20, 3年前 , 64F
git是死的，人是活的。
10/21 17:20, 64F
→
10/21 17:23, 3年前 , 65F
這種專案管理的方式與git本身技術與gir規範無關了，而是要
10/21 17:23, 65F
→
10/21 17:23, 3年前 , 66F
問你們組織，為什麼專案程式碼要這樣管理。
10/21 17:23, 66F
推
10/21 18:52, 3年前 , 67F
如果有大量CICD的話、分開來PR比較方便管理
10/21 18:52, 67F
→
10/21 19:01, 3年前 , 68F
那你說用手抓飯吃是對的還是用筷子吃飯是對的？又或是用
10/21 19:01, 68F
→
10/21 19:01, 3年前 , 69F
刀叉吃飯才是對的呢？
10/21 19:01, 69F
推
10/21 22:50, 3年前 , 70F
我不敢說對錯 但如果是我的話不會這樣幹
10/21 22:50, 70F
→
10/21 23:44, 3年前 , 71F
A rebase onto master就可以了吧? 晚點我試一下
10/21 23:44, 71F
→
10/22 00:01, 3年前 , 72F
哈不行，這樣就只能cherry pick了
10/22 00:01, 72F
→
10/22 00:08, 3年前 , 73F
這種感覺吧
10/22 00:08, 73F
推
10/22 01:43, 3年前 , 74F
看起來還好啊 問題在哪
10/22 01:43, 74F
推
10/22 10:19, 3年前 , 75F
不會說有對錯，但絕不這麼做。要麼拆成三個repo，要嘛
10/22 10:19, 75F
→
10/22 10:19, 3年前 , 76F
就都在master
10/22 10:19, 76F
→
10/22 15:46, 3年前 , 77F
我是比較喜歡在branch上面又長出branch 當然 如果是個人
10/22 15:46, 77F
→
10/22 15:46, 3年前 , 78F
自己的branch就無所謂 自己的branch想怎麼完就怎麼玩
10/22 15:46, 78F
→
10/22 15:47, 3年前 , 79F
但你的例子branch A/B/C似乎是有多人在用 不建議在長出
10/22 15:47, 79F
→
10/22 15:47, 3年前 , 80F
branch 一段時間後會亂到無法無天
10/22 15:47, 80F
→
10/22 15:48, 3年前 , 81F
另外 如果是不同的service 這樣最好code repo各自獨立
10/22 15:48, 81F
→
10/22 16:24, 3年前 , 82F
第一個推文是不喜歡 打錯了
10/22 16:24, 82F
推
10/22 17:25, 3年前 , 83F
追求正確是無意義的 你該說服他們的是有沒有比較「方便
10/22 17:25, 83F
→
10/22 17:25, 3年前 , 84F
」
10/22 17:25, 84F
→
10/22 17:25, 3年前 , 85F
有沒有什麼痛點他們可以改個git方式就處理掉
10/22 17:25, 85F
推
10/23 13:21, 3年前 , 86F
git 就是這樣，規則講好，code review/branch policy弄好，大
10/23 13:21, 86F
→
10/23 13:21, 3年前 , 87F
家跟著就行了。你在那邊不便多說，是要大家通靈喔
10/23 13:21, 87F
推
10/24 10:10, 3年前 , 88F
通常devops or platform eng 是菜鳥或不太懂怎麼分切環
10/24 10:10, 88F
→
10/24 10:11, 3年前 , 89F
境,就會弄一個很困惑的git flow讓 sde先擋一陣子,但用一
10/24 10:11, 89F
→
10/24 10:12, 3年前 , 90F
陣子服務上線後,又沒有膽子去重寫又沒人會,就會變成這樣
10/24 10:12, 90F
→
10/24 10:15, 3年前 , 91F
而且我建議,不要在主專案下亂開branch,在 fork 出來的
10/24 10:15, 91F
→
10/24 10:17, 3年前 , 92F
repo開feature branch,都改好後再發MR,這樣你改其他服務
10/24 10:17, 92F
→
10/24 10:18, 3年前 , 93F
主幹道的commit history也能看得一清二楚
10/24 10:18, 93F
推
10/27 17:18, , 94F
如果管repo的人是不同單位，開repo要填申請單還要層層審
10/27 17:18, 94F
→
10/27 17:18, , 95F
核。人員調動要改權限，三個repo要填三張單，就不難理解
10/27 17:18, 95F
→
10/27 17:18, , 96F
為什麼一個repo當三個用
10/27 17:18, 96F
推
10/28 20:52, , 97F
乾脆連辦公桌椅都自備好了 我猜原本是想搞像 FB 那樣 mon
10/28 20:52, 97F
→
10/28 20:52, , 98F
o repo
10/28 20:52, 98F
→
10/28 20:53, , 99F
期待不同 team 的工程師彼此隨時可以 support switch pro
10/28 20:53, 99F
→
10/28 20:53, , 100F
ject
10/28 20:53, 100F
→
11/02 12:59, , 101F
monorepo?
11/02 12:59, 101F
‣ 更多 pttdocc 的文章
文章代碼(AID): #1ZKMkCMk (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 pttdocc 的文章
文章代碼(AID): #1ZKMkCMk (Soft_Job)