GIT之狐朋狗友

前面几篇我们介绍了GIT的由来，对日常开发所用到的一些常用命令，还介绍了GIT support 或者 integrator 所需要的一些个比较 “复杂”的命令。有了以上这些内容了，基本就可以搭建一个GIT 公共代码库，大
4000
家也都能在上面进行开发。
GIT跟Clearcase等不同的还有一点，就是每个developer拿到的都是整套代码的镜像，包括了源代码以及所有相关的配置信息，历史信息等。如果不对权限进行控制的话，公共代码库很容易就会失控。如何对代码库进行权限控制呢？
 
1.GITolite
Gitolite 是一款 Perl 语言开发的 Git 服务管理工具，通过公钥对用户进行认证，并能够通过配置文件对写操作进行基于分支和路径的的精细授权。GITolite 采用的是SSH协议，并需要使用公钥 验证。也就是说 GITolite会根据管理员预先定义好的设置，根据客户的SSH，对于来自不同客户端的请求进行权限控制，只读，或者读写，甚至于精确到某个文件夹，某个文件的权限。
要使用GITolite，首先要在服务器上安装GITolite，这个参考一下官网（https://github.com/sitaramc/gitolite）。当安装完毕之后，在服务器端会自动生成一个GITolite的repository - gitolite-admin.git. 这时，管理员需要克隆一个gitolite-admin到team
pc或其他公共的地方，方便后面的管理。
克隆完毕后，我们可以在gitolite-admin下面发现两个目录：conf/ 和 keydir/
conf/gitolite.conf就是授权配置文件，里面写着谁谁谁有什么样的权限，比如

#gitolite conf
# please see conf/example.conf fordetails on syntax and feature 
repo gitolite-admin
   RW+= admin
repo testing
   RW+= @all

 
keydir/ 里面则是存放着需要授权的developer的SSH public key。
当我们需要为developer添加一个key的时候，我们将developer的这个key放到前面 keydir文件夹，然后在gitolite-admin这个repository里面，将新增的文件加到index，commit 并且push到 gitolite的服务端，这样，授权就基本完毕了。当然，如果需要特别的权限设置，这时还需要管理员去修改conf/gitolite.conf 文件。
因为我们项目只是用了GITolite很小的一个功能，所以对这个的一些细节或者深层次的东东不是很了解。这里就基于自己所知道的，粗略讲一些。之前经常参考的地方时官网 跟 群英汇的东西 （http://www.ossxp.com/doc/git/gitolite.html）

2.Gerrit
前面我们说到了对Gitolite是对于开发人员的一种授权，但一旦保证了授权，就能够保证版本库的稳定吗？如果获得授权的人乱搞代码，或者改错代码，那版本库照样会出现不稳定的情况的。就像前面在敏捷系列里面说到的一样，在代码改动之后，要引入code review (代码审阅，说code review
比较顺口，还是用code review吧)。在Clearcase条件下，code review是需要把别人的代码整进去版本库之后，再由code reviewer拿下来看的。于是在Google Android项目的开发过程当中，Google为GIT带来了又一个伟大的工具-Gerrit，也有人叫Gerrit2，因为现在用的Gerrit跟Google刚开始整的时候有很大的不同，我们暂且叫它Gerrit就可以。
Gerrit有两个很牛的功能，第一是权限管理，它提供了一个跟GITolite一样的功能，管理用户的读写权限。但它比GITolite好用，对权限的控制都在它提供的网页系统里面完成，不用push啥的！第二是Gerrit为GIT带来强制性的code review，除非你某某是管理员。任何的代码改动都需要有人approve之后，这个代码改动才有可能进入公共代码库，如果没有经过approve或者被人reject了，即使你已经push了五百年，这代码依旧进不了公共版本库。而且
相比起裸奔时代的code review，Gerrit提供一个在线review 的系统，所有的操作都在它提供的系统上面点点点就能搞定的。
首先我们来看看权限控制，Gerrit有10种不同的权限，其中有读写权限，code review的权限等等。每个权限的设置包括两部分：权限本身，以及权限授予的组。下面大约介绍几种:(下面以版本2.1.8的来说，版本2.2.2之后权限设置有点不同)

1) Read Access
这是读写权限，总共有3个级别：1级代表只读；2级代表可以上传一些代码改动，不能包含任何merge的commit，也就是说你的代码库必须基于最新的版本进行修改；3级代表的是 可以上传任何代码修改。一般情况下，内部的开发人员都要用3级的。

2）Push Branch
这是对于Branch操作的权限，也是有3个级别的：1级代表可以更新Branch的信息；2级表示可以创建Branch; 3级代表可以更新Branch，创建Branch，删除Branch。还有一个超级无敌的权限:你的 code change可以绕过 code review系统，直接进去公共代码库。上面说的除非你某某是管理员，如果是并且他愿意的话，他就在这里给你设置一个权限，你就可以为所欲为！

3）Code Review
这是设置用户在code review系统上面的权限，这级别就多了去了，而这个级别同时也是你能打的分数。打-2说明你reject了别人的代码；打-1说明你对别人的代码唧唧歪歪；打0表示你木意见；打1说明你觉得还成，但心里还是没底，还需要别人把关；打2说明你觉得very
 good，代码可以出山了！任何一个代码改动都需要至少得到一个+2分的评价，再加verify+1 的评价，才能进入到公共代码库。如何强制代码一定要通过code review呢？首先就是权限设置要弄好咯，一般情况下 不允许任何人可以绕过code review；前面我们说过 push的时候大概是用命令"git
 push origin HEAD:refs/heads/BRANCH",但在用了Gerrit之后，这样的命令说明你想绕过code review，一般都会不成功的。这时需要稍作手脚，把命令改成 "git push origin HEAD:refs/for/BRANCH".当然，除了这个之外，origin的地址也应该是code
review这个系统提供的URL，而不是公共代码库，比如"ssh://YOUR_ID@codereview.com:29418/project.git".

3.Jenkins
如果用了Gerrit，那么每一个代码改动都要经过code review approve 并且要验证。code review还好说，可验证就麻烦了。如果每个改动都要人手拿到本地，至少去确保能编译通过吧，那谁都会疯了的！！！话说IT人的精品特质之一就是懒，所以有繁琐的地方
 往往都会产生自动化 （这貌似也是工业能够向前发展，甚至于社会能够向前发展的一个因素哦，要发扬发扬）。Jenkins就应运而生了。
Jenkins， 曾用名Hudson，是基于Java开发的持续集成的工具。它能够自动监控到公共代码库的版本变更，并且执行我们预先定义好的动作。在动作完成之后，把动作执行的结果回传给有关部门！比如我们可以让Jenkins监听Gerrit上面的代码变更情况，看有没有人提出code review的请求。如果监听到请求，那么Jenkins就偷偷向Gerrit要那个人改了的代码，试着做一些编译以及单元测试。如果这人很牛叉，测试通过。那么Jenkins会告诉Gerrit
：“喂，这条友很牛哦，我向毛主席保证，TA的代码改动没有问题”，这时Gerrit就跑过去将这个review item的 verify设置为+1，如果不通过，那就铁面无私地给一个 verify-1.
对于Jenkins的设置，很抱歉，一直没时间去仔细弄弄，回头再补补吧！

上面就是GIT的一些个狐朋狗友，可能你回觉得设置很烦，甚至注册的时候就已经很烦了，但对于gerrit，我想说：谁用谁知道！对于Gerrit部分的介绍略显得少，上次给同事讲的时候用了大概3个钟头 才讲了个大概，后面看看有没有时间写多一点。

好了，GIT的狐朋狗友就大概介绍到这里。如果你还想了解多一些关于从Clearcase 迁移到GIT的一些痛苦，以及当GIT集成了Gerrit，甚至是Jenkins之后的工作流程的话，敬请关注一下日志！