将git master主分支作为空分支的另类用法

好像也有人将master主分支建成空分支这么用，不过还没有见到类似的文章，故我写一篇文章分享一下吧。

情形是这样的，公司建了私服以后，因为svn和git理念不用，git单独检出部分文件很费劲，所以强迫各个项目组将文档和代码进行了分类。这也许也是很多公司文档管理要单独用各系统的原因所在吧。不过单独文档管理（分权限）虽然好，但是有些时候欠缺了灵活性。尤其是对于敏捷开发来说，普及一些文档，过于繁琐。而且由于现在代码前后端分离，加上各种小程序、手机等工程，建立的代码仓库像下崽一样，多的人眼花缭乱。如果只是为一个公司服务还好。但是要是多家公司、多个不同业务派生，不同的业务端代码打分支，最后想要针对业务或者公司去管理项目，也成了一件头疼的事（当然git可以选择建立分类，部分解决这种困扰）。

于是乎，俺想到了一个另类的做法。把master做成空分支，这样的话，下面的所有分支都可以继承这个空分支，随心所欲的放各自的代码，并且可以将文档的每个章节做成一个分支，检索的时候，只检索分支章节即可。如下图，然后在创建一个全部的章节目录，将其他分支合并到全部即可。

我将这种不自己创建文件，依靠其他分支合并提交的分支叫做合并分支。

在权限控制上，master设定为保护分支，只允许提交代码，“全部”分支设定为只允许合并请求才能提交代码，这样就保障了开发不会随意提交文档到合并分支上。

当然git的保护毕竟不如专业的文档管理，如果介意文档目录权限，不建议用这种方式。但是这种方式确实是解决了文档放在master管理这种令人头疼的情况。

扩展开来，有了master这种空分支方法，可以将前后端代码和各种不同的代码都放到一个代码仓库中，可以一个代码仓建立多个不同的代码合并分支。

有开发提出来，将前后端放在一个代码仓，一切换分支，代码没了。我说他没想明白，以前前后端代码两个仓，需要启动开发工具各拉一边代码，现在一个仓，起两个工具拉两边代码是一样的，没有增加开发的麻烦，但是给项目带来了整齐。

当然也有它的弊端，前后端代码容易被一锅端。不过前后端代码通用的封装已经成为了jar和一个npm组件，风险性也降低了。

如果git能做到每个分支分配权限就完美了。