玩儿了这么多年 Linux ，编译、安装、搭建、配置过的软件、项目不计其数，虽然没玩过 LFS 不敢自称大牛，但自认为折腾能力还是不错的。可是这次搭建 Gitlab 给了我一次不大不小的打击。第一次搭建还以失败告终，重来了一次才成功，浪费了不少时间。在此记下一些心得，以给各位提供一些建议。
首先，这不是一篇 Step by Step 的小白指南，而只是一些较为宽泛的笔记，不针对某个特定版本。具体的安装方法还请按照官方文档。其次，即使你是经验丰富的“高手”，我也建议你浏览一下这篇日志，就算只是扫一眼小标题也好，也许将会为你节省不少时间。
1. 正确选择分支—— Master 不是稳定版！
我是 Archlinux 用户，自然安装过不少 AUR 包，其中不少是从 git 上获取的（foo-git），自己也写过一些 PKGBUILD ，不知不觉中产生了 master 分支就是最新稳定版（或者是相对稳定的 RC 或 beta 版）的概念。然而 Gitlab 的 master 分支是连 CI 测试都可能无法通过的 bleeding edge ，是主开发分支！如果能够顺利安装完成，只能算你运气好，正好 checkout 出了一份勉强能够搭建的版本。而且在进入发布阶段前，文档是不会更新的，所以即使代码没有问题，按照文档也可能无法完成安装。
按照官方文档，应该 checkout 到最新的稳定分支（-stable），根据该分支 doc 目录下的文档来进行安装配置。然而，我发现其实就算是 -stable 也不一定是稳定版，只是表示这个分支处于“稳定版”通道中，可能是“正在成为”稳定版。比如我安装时选择的 6-0-stable ，结果安装时报了个错，安装结束后界面上显示的居然是 6.0 beta 。只有当官方博客宣布某版本发布时，相应 branch 才是最新的稳定版本。
2. 严格遵循文档依照默认配置！
很多老手都有自己的配置习惯，不喜欢按照文档一步一步照着命令敲，会根据自己的喜好和实际情况做一些修改。然而对于 Gitlab ，这将很成问题。在第一次安装的一开始，我曾想使用 gitlab 作为用户名，而非文档中的 git 。后来发现代码中有无数初配置涉及用户名，甚至还有一些 hard code ，全部都默认用户名为 git 。总不能把 git 全部替换成 gitlab 吧？一处处手工修改简直是噩梦，最后不得不放弃。其他一些配置也同理。尽量不要做出修改，依照文档和默认值。因此推荐在一个干净的机器上搭建 Gitlab ，以免受到其他应用和旧配置的影响。
3. 安装过程中最好翻墙或及时更换 Ruby gems 仓库地址
这个应该是在国内服务器安装 Ruby 应用所面临的共同问题吧， rubygems.org 连接性非常堪忧，建议使用淘宝 Ruby gems 镜像。需要替换两次，第一次是更换系统的 gems source ，第二次是修改 Gitlab 的 Gemfile 。
4. 生产环境勿搭建在非官方支持的平台上
这就不多说了，看了上面的两点之后，还想手贱自己试试看的我也拦不了你了……生产环境还是以效率和稳定性为第一，不要自己瞎折腾吧。
UPDATE: 一个小贴士，不要在运行过程中情况 Redis 缓存，先把服务停掉再说……