个人意见，仅供参考 不太确定常不常见，但看起来是合理的。 可以想到的好处和情况是 不同的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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1666414528.A.448.html ※ 编辑: dingdingcho (75.7.116.251 美国), 10/22/2022 12:56:57