好像也有人将master主分支建成空分支这么用,不过还没有见到类似的文章,故我写一篇文章分享一下吧。
情形是这样的,公司建了私服以后,因为svn和git理念不用,git单独检出部分文件很费劲,所以强迫各个项目组将文档和代码进行了分类。这也许也是很多公司文档管理要单独用各系统的原因所在吧。不过单独文档管理(分权限)虽然好,但是有些时候欠缺了灵活性。尤其是对于敏捷开发来说,普及一些文档,过于繁琐。而且由于现在代码前后端分离,加上各种小程序、手机等工程,建立的代码仓库像下崽一样,多的人眼花缭乱。如果只是为一个公司服务还好。但是要是多家公司、多个不同业务派生,不同的业务端代码打分支,最后想要针对业务或者公司去管理项目,也成了一件头疼的事(当然git可以选择建立分类,部分解决这种困扰)。
于是乎,俺想到了一个另类的做法。把master做成空分支,这样的话,下面的所有分支都可以继承这个空分支,随心所欲的放各自的代码,并且可以将文档的每个章节做成一个分支,检索的时候,只检索分支章节即可。如下图,然后在创建一个全部的章节目录,将其他分支合并到全部即可。
我将这种不自己创建文件,依靠其他分支合并提交的分支叫做合并分支。
在权限控制上,master设定为保护分支,只允许提交代码,“全部”分支设定为只允许合并请求才能提交代码,这样就保障了开发不会随意提交文档到合并分支上。
当然git的保护毕竟不如专业的文档管理,如果介意文档目录权限,不建议用这种方式。但是这种方式确实是解决了文档放在master管理这种令人头疼的情况。
扩展开来,有了master这种空分支方法,可以将前后端代码和各种不同的代码都放到一个代码仓库中,可以一个代码仓建立多个不同的代码合并分支。
有开发提出来,将前后端放在一个代码仓,一切换分支,代码没了。我说他没想明白,以前前后端代码两个仓,需要启动开发工具各拉一边代码,现在一个仓,起两个工具拉两边代码是一样的,没有增加开发的麻烦,但是给项目带来了整齐。
当然也有它的弊端,前后端代码容易被一锅端。不过前后端代码通用的封装已经成为了jar和一个npm组件,风险性也降低了。
如果git能做到每个分支分配权限就完美了。