个人意见,仅供参考
不太确定常不常见,但看起来是合理的。
可以想到的好处和情况是
不同的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使用方式? 是否合理? 谢谢。