我们打算在项目组内部尝试使用Git，原因不多说了,最核心的目的是为了提高开发效率。
为了兼容之前的Svn方案和其他一些项目制约，我们有以下目标：
首先git的使用正常
其次，要能实时和svn仓库保持同步
最好支持权限
可以通过界面浏览就更好了
在部署我们的Git环境中，有一些问题和注意点，此处记录下来。
##基于GitBucket + SubGit
起初，基于部署难易程度、二次开发难易程度和项目组以后技术的发展方向考虑，以及使用的简便性，界面的观赏性等因素选择了GitBucket。SubGit是保证git和svn同步的工具，在其他方案中也是必选。SubGit选择的是官方最新的稳定版（2.0.3）。
GitBucket部署很简单，参照官方说明一切OK。但和SubGit集成的时候出现问题，发现，Svn的提交可以同步过来，但是Git的提交无法同步的Svn。经过排查，最终发现是由于GitBucket不支持 git的script hook，就是，提交后不会执行git的钩子。而SubGit的同步实现依赖于钩子的触发，所以没有办法。如果同一个仓库通过原始的SSH方式访问，就可以达到同步的目的。
这种方案，实际上是失败了
##基于GitLab + SubGit
在GitBucket无法达到要求的情况下，转而选择应用广泛的GitLab来搭建Git服务器环境。SubGit版本不变。
GitLab依赖的东西比较多，包含Mysql 、Redis等等。为了方便起见，使用的GitLab Installer。起初选择64位版本，在10.213服务器（CentOS 5 64 位）上安装多次，均无法成功。表现是，安装过程中会出现一点问题，最后提示安装成功，但是无法打开GitLab页面（未启动）。后选择32位版本测试，在服务器上面安装成功（但这个不是根本原因，时间关系，未深入排查）。
虽然安装成功，但是在配置SubGit同步的过程中发现，无法正确向Git仓库提交代码，由于SubGit脚本（之前提到的hook）执行失败而被拒绝。在SubGit官方Issue系统中查找到此问题为和GitLab整合的一个Bug。按照Bug中说明的问题，尝试手动修复，未成功。然后下载SubGit的最新EAP版本，尝试，仍未成功。在这个时候发现新的错误原因为 Permission Denied，通过修改Git Repositories目录及子目录（文件）权限为777解决。
在测试中发现svn和Git的普通同步已经OK了，但是Gitlab CI 集成好像没有触发，时间原因没有进一步排查。
这种方案，应该算80%成功。
##基于Gitolite + SubGit
由于使用GitLab过程中出现很多问题，而且安装配置复杂，再加上Ruby项目组无人熟悉，而且，我们期望一个 稳定 的Git环境使用来保证Git 推广的顺利 ，所以最后又尝试使用Gitolite 配合 SubGit来做。
使用Gitolite的问题主要是安装运行的问题。在这次安装过程中，手工配置git账号，将相关程序都以该身份运行。由于之前有其他系统（前几个方案）和系统本身环境的因素，在账号和bash运行出现了较多问题，影响最大的就是没有Git命令。后发现，Gitolite脚本对于git依赖有特殊说明，如果git在非标准目录安装，需要在~/.gitolite.rc脚本头部作如下指定：
1 | $ENV{PATH} = "/git/path:$ENV{PATH}" #其中/git/path是git路径 |
在按照官方文档配置后问题基本解决，测试的时候发现svn 和 Git的同步按照默认的subGit分支配置无法同步 包含”/”的分支，如特性分支 feature/* 发布分支 release/* 等，最后，基于git-flow，在SubGit中指定了几种包含/的特定分支，比如，feature：
1 | [svn] |
这样就可以同步这些特殊分支了，不过，需要在每个仓库中配置。
在Gitolite权限配置的时候，注意创建仓库的权限按照网上部分文章的说法，只给C是不行的，需要再加一行
1 | RW+ = CREATOR |
才可以。其他相关权限配置就参照Gitolite说明即可。
在此基础上，通过使用软链接的方法，又结合了GitBucket测试。将Gitolite的repositories目录链接到GitBucket的repositories的目录，在GitBucket中建立对应的用户，添加对应的仓库（这些都以Gitolite为主），这时候会报错，不管他，然后就会发现，Gitolite仓库对GitBucket可见了。
