Gitlab：缺乏工程性的项目

GitLab是一款界面类似GitHub的Git管理软件。虽然很强大，但是在工程性上欠佳。

GitLab的开发很快，也很流行。到官方博客去看，差不多一个月一个小版本，几个月就出一个大版本。3.0还是去年10月发布的，现在master分支已经是针对5.0的了，应该很快就要发布了。这些大版本都有重大的不兼容引入。

4.0前，仓库是在一个名字空间内。4.0开始，仓库是按用户名来区分的，类似GitHub的user/repo的命名方式。这和之前版本的用法是不兼容的。如果用户不想用这种用户名区分的仓库命名方式，想安装去年11月发布的3.1，就不能按照官方给出的文档地址来安装。因为这个是stable分支，现在指向的是4-1-stable，我们需要切换到3.1分支的文档来参考安装。

仅仅3月多月前的稳定版都没有一个正确的安装文档。这个文档里面init script和Nginx配置文件的地址分别是：https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab和https://raw.github.com/gitlabhq/gitlab-recipes/master/nginx/gitlab。master分支已经针对5.0了，和3-1-stable不兼容。gitlab-recipes这个项目没有针对3.1的分支。怎么办呢？我只好按照GitLab 3.1的发布日期2012年11月22日，去找到gitlab-recipes最接近那天的版本，下载这个版本的配置文件。

从4.1版本开始，GitLab的作者已经全职开发GitLab。充足的时间让这款软件的演进速度很快，但由于作者更专注于新功能的开发，而忽略了维护工作，导致文档缺乏，没有一个长期支持的稳定版本，缺乏对发行版本生命周期的管理。

GitLab一直依赖他们fork的Gitolite。5.0开始，将不依赖Gitolite，而用他们自己开发的GitLab Shell来管理仓库。有用户提出，之前GitLab宕了Git仓库还能访问（Gitolite是独立的）；这样改动后，GitLab如果宕了整个Git仓库就不能访问了。

此外，GitLab安装过程繁琐，容易出错，而目前没有打包好的安装包。我觉得这对推广软件是很重要的，但貌似作者并不重视发行渠道。

根据我安装GitLab的经历，我觉得目前的GitLab还不太适合企业里面全面推广和长期部署。