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

個人意見，僅供參考

不太確定常不常見，但看起來是合理的。

可以想到的好處和情況是

不同的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)》之銘言：

讓

而

階

改

,

--