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

看板Soft_Job作者 (dingding)時間1年前 (2022/10/22 12:55), 1年前編輯推噓11(12推 1噓 27→)
留言40則, 13人參與, 1年前最新討論串2/2 (看更多)
個人意見，僅供參考 不太確定常不常見，但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build，Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境，利於不同進度的開發和整合。 舉例來說， 小明主要負責Service A 的開發，小美主要負責Service B的開發，假定星期四有統一的w eekly release 。 星期一 小明在Service A增加了新的feature, - 小明把他code merge 進branch A - branch A 的pull request merge trigger 了Build pipeline - 當Build 完成之後，自動把小明新增的feature deploy 到Service A的測試環境 - 小明在service A的測試環境上測試他的新feature 星期二 小美改了Service B的一個bug - 小美把code merge 進branch B - branch B的pull request merge trigger 了Build pipeline - 當Build 完成之後，自動把小美改的bug fix deploy 到Service B的測試環境 - 小美在service B的測試環境上測試bug 到底是不是真的有修好 星期三 靠杯，小明發現Service A那個新的feature有問題，service A這個feature來不及趕上星 期四的weekly deployment。 而小美在測試環境上測試過，Service B的bug 已經改好了。 小明跟小美說：我ok，你先請 於是，小美把branch B Merge 進 Master Branch 星期四 Weekly deployment 的時候，將master branch 到production 的環境。 這週的release 中，包含了小美Service B的bug fix ，但是沒有包含小明在Service A中 需要新增到feature 。 以上的例子說明 小明的service A的開發進度，並不會影響weekly release 中小美service B bug fix 的 時程 反之，如果今天只有一個master branch ， 而大家都把code merge 進去master branch 再deploy 到開發環境測試， 就上述的例子而言，如果小明來不及在weekly release 前改好他新加的feature， 那麼可能需要延後既定的release 時間， 或者小明需要加班趕進把新的feature 修好merge 進master branch ， 或者在master branch 上revert 小明的code change而更麻煩。 另外一種常見的作法是， 一般可能會有一個develop branch 和一個master branch ， Develop branch 通常被用來部署到測試環境 Master branch 通常被用來部署到production 環境 這個作法也可以用來確保code 有在測試環境被測試過。 至於你提到的，有人直接 check out master branch ，再merge 回master branch ， 我覺得聽起來很像新手會做的事XD 可以避免這件事的作法， 是設定master branch 不允許code 直接push ，而是只允許Pull Request Merge。 吧啦吧啦，說了一大堆， 最後結論，我認為沒有所謂的一定最好的方法， Branch 用法，關係到軟體架構、開發流程、CICD的設置、部署的時程，等等， 今天一個軟體只有兩個人開發，那一個master branch 可能就足夠了 今天可能開發團隊有十幾個人， 或是一個repo 包含各種不同的service， 那麽把 branch 區分出來的這種作法也是可以被理解的， 不同的用法，可以討論的點太多了， 總之重要的，還是要你們開發團隊協調好就好。 引述《pttdocc (Hi)》之銘言： : 請問一下，本人是程式新手，最近加入了一個組織，裡面的開發團隊的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), 來自: 75.7.116.251 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1666414528.A.448.html ※ 編輯: dingdingcho (75.7.116.251 美國), 10/22/2022 12:56:57
推
10/22 13:30, 1年前 , 1F
“靠杯”語助詞，下得很棒！
10/22 13:30, 1F
推
10/22 14:40, 1年前 , 2F
你描述的問題用 feature flag 或 cherry-pick 都能解
10/22 14:40, 2F
→
10/22 14:40, 1年前 , 3F
決吧。
10/22 14:40, 3F
推
10/22 15:31, 1年前 , 4F
說真的這個情況三個repo更合理，不過用branch不是不行
10/22 15:31, 4F
噓
10/22 16:14, 1年前 , 5F
10/22 16:14, 5F
推
10/22 21:16, 1年前 , 6F
如果這樣就要用3個repo也太複雜了吧。現在看來反而是他們
10/22 21:16, 6F
→
10/22 21:16, 1年前 , 7F
公司沒有鎖master才有問題，使用上沒什麼問題
10/22 21:16, 7F
→
10/22 21:20, 1年前 , 8F
我反而覺得應該是原原po沒有說清楚，master裡面“只有”
10/22 21:20, 8F
→
10/22 21:20, 1年前 , 9F
這三個不相依的項目嗎？是不是其實還有會被共用的東西之
10/22 21:20, 9F
→
10/22 21:20, 1年前 , 10F
類的
10/22 21:20, 10F
推
10/23 10:28, 1年前 , 11F
依照原原po的說法是在根目錄上有三個獨立資料夾，應該是
10/23 10:28, 11F
→
10/23 10:28, 1年前 , 12F
完全不相依的感覺。感覺有點像是當初懶得寫公司煩得要死
10/23 10:28, 12F
→
10/23 10:28, 1年前 , 13F
的it單就乾脆一個repo管理三個獨立專案了。
10/23 10:28, 13F
推
10/23 10:52, 1年前 , 14F
不是都有develop, staging, master
10/23 10:52, 14F
→
10/23 10:52, 1年前 , 15F
master 只merge hotfix 或staging
10/23 10:52, 15F
→
10/23 10:53, 1年前 , 16F
staging 內容跟master 一樣，只是用來測試的地方
10/23 10:53, 16F
→
10/23 10:54, 1年前 , 17F
develop 會定期merge master 上的穩定內容，也是一般
10/23 10:54, 17F
→
10/23 10:55, 1年前 , 18F
開發是checkout -b 出來的 branch
10/23 10:55, 18F
推
10/23 13:23, 1年前 , 19F
故事不錯我喜歡
10/23 13:23, 19F
推
10/23 16:29, 1年前 , 20F
很清楚
10/23 16:29, 20F
推
10/23 18:49, 1年前 , 21F
用 submodule 呢？
10/23 18:49, 21F
推
10/23 22:54, 1年前 , 22F
Hi, 我是原原po, 補充說明一下, 星期一、二的例子是說明
10/23 22:54, 22F
→
10/23 22:55, 1年前 , 23F
分ABC branch的話build pipeline自動trigger時比較方便知
10/23 22:55, 23F
→
10/23 22:55, 1年前 , 24F
到要build 哪個項目, 這點在例子裡我同意 不過我們出
10/23 22:55, 24F
→
10/23 22:56, 1年前 , 25F
build的系統是merge好後要手動trigger的 這時可以選要
10/23 22:56, 25F
→
10/23 22:57, 1年前 , 26F
build 哪些項目, 而分develop和master branch,中間還會有
10/23 22:57, 26F
→
10/23 22:57, 1年前 , 27F
staging(release)branch的作法, 這個我知道, 不過我們
10/23 22:57, 27F
→
10/23 22:58, 1年前 , 28F
沒有搞那麼複雜, 就是master branch, 要作feature時分
10/23 22:58, 28F
→
10/23 22:59, 1年前 , 29F
一個branch出去, 要merge回master brach前, 先把master b
10/23 22:59, 29F
→
10/23 22:59, 1年前 , 30F
branch的東西merge回來測試, 這樣子如果遇到有解master
10/23 22:59, 30F
→
10/23 23:00, 1年前 , 31F
branch merge回來的conflict時, 的確可能feature branch
10/23 23:00, 31F
→
10/23 23:01, 1年前 , 32F
build好測過, 但merge回master時又有問題(理論上),但大致
10/23 23:01, 32F
→
10/23 23:01, 1年前 , 33F
上運作起來還算OK, 另外就是 我同意其實可以分3個獨立
10/23 23:01, 33F
→
10/23 23:03, 1年前 , 34F
的repo, 這3個service是開發時比較沒dependency, 但性
10/23 23:03, 34F
→
10/23 23:04, 1年前 , 35F
質上有些相關, 所以當初才會放一起, 最後就是, 其實我大
10/23 23:04, 35F
→
10/23 23:05, 1年前 , 36F
略的了解比較偏向是當初開repo的人自已發明這套作法 覺
10/23 23:05, 36F
→
10/23 23:05, 1年前 , 37F
得這樣分好像很好 還有我竟然用推文打了那麼多行 謝謝
10/23 23:05, 37F
→
10/23 23:05, 1年前 , 38F
以上
10/23 23:05, 38F
推
10/24 21:11, 1年前 , 39F
看到一半也是想說這不是在講 cherry-pick嗎... XD
10/24 21:11, 39F
推
10/25 23:22, 1年前 , 40F
這樣是很好呀，有什麼不好的？
10/25 23:22, 40F
‣ 更多 dingdingcho 的文章
文章代碼(AID): #1ZKtV0H8 (Soft_Job)
‣ 更多 dingdingcho 的文章
文章代碼(AID): #1ZKtV0H8 (Soft_Job)