5.4.1.1. 安装之前¶

Gitolite搭建的Git服务器是以SSH公钥认证为基础的，无论是普通Git用户还是Gitolite的管理员都通过公钥认证访问Gitolite服务器。在Gitolite的安装过程中需要提供管理员公钥，以便在Gitolite安装完毕后管理员能够远程克隆gitolite-admin版本库（仅对管理员授权），对Gitolite服务器进行管理——添加新用户和为用户添加授权。

为此在安装Gitolite之前，管理员需要在客户端（用于远程管理Gitolite服务器的客户端）创建用于连接Gitolite服务器的SSH公钥（如果尚不存在的话），并把公钥文件拷贝到服务器上。

1. 在客户端创建SSH公钥/私钥对。

   如果管理员在客户端尚未创建公钥/私钥对，使用下面的命令会在用户主目录下创建名为~/.ssh/id_rsa的SSH私钥和名为~/.ssh/id_rsa.pub的公钥文件：

   $ ssh-keygen
   

2. 将公钥文件从客户端复制到服务器端，以便安装Gitolite时备用。

   可以使用ftp或U盘拷贝等方式从客户端向服务器端传送文件，不过用scp命令是非常方便的，例如服务器地址为server，相应的拷贝命令为：

   $ scp ~/.ssh/id_rsa.pub server:/tmp/admin.pub
   

5.4.1.2. 以发布包形式安装¶

常见的Linux发行版都包含了Gitolite软件包，安装Gitolite使用如下命令：

• Debian/Ubuntu：

  $ sudo aptitude install gitolite
  

• RedHat：

  $ sudo yum install gitolite
  

安装完毕后会自动创建一个专用系统账号如gitolite。在Debian平台上创建的gitolite账号使用/var/lib/gitolite作为用户主目录，而非/home/gitolite。

$ getent passwd gitolite
gitolite:x:114:121:git repository hosting,,,:/var/lib/gitolite:/bin/bash

安装完毕，运行如下命令完成对Gitolite的配置：

1. 切换至新创建的gitolite用户账号。

   $ sudo su - gitolite
   

2. 运行gl-setup命令，并以客户端复制过来的公钥文件路径作为参数。

   $ gl-setup /tmp/admin.pub
   

Debian等平台会在安装过程中（或运行sudo dpkg-reconfigure gitolite命令时），开启配置界面要求用户输入Gitolite专用账号、Git版本库根目录、管理员公钥文件名，然后自动执行gl-setup完成设置。

5.4.1.3. 从源代码开始安装¶

如果想在系统中部署多个Gitolite实例，希望部署最新的Gitolite版本，或者希望安装自己或他人对Gitolite的定制版本，就要采用从源代码进行Gitolite部署。

1. 创建专用系统账号。

   首先需要在服务器上创建Gitolite专用帐号。因为所有用户都要通过此帐号访问Git版本库，为方便易记一般选择更为简练的git作为专用帐号名称。

   $ sudo adduser --system --group --shell /bin/bash git
   

   注意添加的用户要能够远程登录，若系统只允许特定用户组（如ssh用户组）的用户才可以通过SSH协议登录，就需要将新建的git用户添加到该特定的用户组中。执行下面的命令可以将git用户添加到ssh用户组。

   $ sudo adduser git ssh
   

   取消git用户的口令，以便只能通过公钥对git账号进行认证，增加系统安全性。

   $ sudo passwd --delete git
   

2. 切换到新创建的用户账号，后续的安装都以该用户身份执行。

   $ sudo su - git
   

3. 在服务器端下载Gitolite源码。一个更加“Git”的方式就是克隆Gitolite的版本库。

   • 克隆官方的Gitolite版本库如下：

     $ git clone git://github.com/sitaramc/gitolite.git
     

   • 也可以克隆定制后的Gitolite版本库，如我在GitHub上基于Gitolite官方版本库建立的分支版本：

     $ git clone git://github.com/ossxp-com/gitolite.git
     

4. 安装Gitolite。

   运行源码目录中的src/gl-system-install执行安装。

   $ cd gitolite
   $ src/gl-system-install
   

   如果像上面那样不带参数的执行安装程序，会将Gitolite相关命令安装到~/bin目录中，相当于执行：

   $ src/gl-system-install $HOME/bin $HOME/share/gitolite/conf $HOME/share/gitolite/hooks
   

5. 运行gl-setup完成设置。

   若Gitolite安装到~/bin目录下（即没有安装到系统目录下），需要设置PATH环境变量以便gl-setup能够正常运行。

   $ export PATH=~/bin:$PATH
   

   然后运行gl-setup命令，并以客户端复制过来的公钥文件路径作为参数。

   $ ~/bin/gl-setup /tmp/admin.pub
   

5.4.2.1. 管理员克隆gitolite-admin管理库¶

当Gitolite安装完成后，就会在服务器端版本库根目录下创建一个用于管理Gitolite的版本库。若以git用户安装，则该Git版本库的路径为：~git/repositories/gitolite-admin.git。

在客户端用ssh命令连接服务器server的git用户，如果公钥认证验证正确的话，Gitolite将此SSH会话的用户认证为admin用户，显示admin用户的权限。如下：

$ ssh -T git@server
hello admin, this is gitolite v2.1-7-ge5c49b7 running on git 1.7.7.1
the gitolite config gives you the following access:
     R   W      gitolite-admin
    @R_ @W_     testing

从上面命令的倒数第二行输出可以看出用户admin对版本库gitolite-admin拥有读写权限。

为了对Gitolite服务器进行管理，需要在客户端克隆gitolite-admin版本库，使用如下命令：

$ git clone git@server:gitolite-admin.git
$ cd gitolite-admin/

在客户端克隆的gitolite-admin目录下有两个子目录conf/和keydir/，包含如下文件：

• 文件：keydir/admin.pub。

  目录keydir下初始时只有一个用户公钥，即管理员admin的公钥。

• 文件：conf/gitolite.conf。

  该文件为授权文件。初始内容为：

  repo    gitolite-admin
          RW+     =   admin
  
  repo    testing
          RW+     =   @all
  

  默认授权文件中只设置了两个版本库的授权：

  • gitolite-admin

    即本版本库。此版本库用于Gitolite管理，只有admin用户有读写和强制更新的权限。

  • testing

    默认设置的测试版本库。设置为任何人都可以读写及强制更新。

5.4.2.2. 增加新用户¶

增加新用户，就是允许新用户能够通过其公钥访问Git服务。只要将新用户的公钥添加到gitolite-admin版本库的keydir目录下，即完成新用户的添加，具体操作过程如下。

1. 管理员从用户获取公钥，并将公钥按照username.pub格式进行重命名。

   • 用户可以通过邮件或其他方式将公钥传递给管理员，切记不要将私钥误传给管理员。如果发生私钥泄漏，马上重新生成新的公钥/私钥对，并将新的公钥传递给管理员，并申请将旧的公钥作废。
   • 用户从不同的客户端主机访问有着不同的公钥，如果希望使用同一个用户名进行授权，可以按照username@host.pub的方式命名公钥文件，和名为username.pub的公钥指向同一个用户username。
   • Gitolite也支持邮件地址格式的公钥，即形如username@gmail.com.pub的公钥。Gitolite能够很智能地区分是以邮件地址命名的公钥还是相同用户在不同主机上的公钥。如果是邮件地址命名的公钥，将以整个邮件地址作为用户名。
   • 还可以在keydir目录下创建子目录来管理用户公钥，同一用户的不同公钥可以用同一名称保存在不同子目录中。

2. 管理员进入gitolite-admin本地克隆版本库中，复制新用户公钥到keydir目录。

   $ cp /path/to/dev1.pub keydir/
   $ cp /path/to/dev2.pub keydir/
   $ cp /path/to/jiangxin.pub keydir/
   

3. 执行git add命令，将公钥添加到版本库。

   $ git add keydir
   

4. 执行git commit，完成提交。

   $ git commit -m "add user: jiangxin, dev1, dev2"
   

5. 执行git push，同步到服务器，才真正完成新用户的添加。

   $ git push
   Counting objects: 8, done.
   Delta compression using up to 2 threads.
   Compressing objects: 100% (6/6), done.
   Writing objects: 100% (6/6), 1.38 KiB, done.
   Total 6 (delta 0), reused 0 (delta 0)
   remote: Already on 'master'
   remote:
   remote:                 ***** WARNING *****
   remote:         the following users (pubkey files in parens) do not appear in the config file:
   remote: dev1(dev1.pub),dev2(dev2.pub),jiangxin(jiangxin.pub)
   

   在git push的输出中，以remote标识的输出是服务器端执行post-update钩子脚本的错误输出，用于提示新增的三个用户（公钥）在授权文件中没有被引用。接下来会介绍如何修改授权文件，以及如何为用户添加授权。

服务器端的git主目录下的.ssh/authorized_keys文件会随着新增用户公钥而更新，即添加三条新的记录。如下：

$ cat ~git/.ssh/authorized_keys
# gitolite start
command="/home/git/bin/gl-auth-command admin",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty    <用户admin的公钥...>
command="/home/git/bin/gl-auth-command dev1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty     <用户dev1的公钥...>
command="/home/git/bin/gl-auth-command dev2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty     <用户dev2的公钥...>
command="/home/git/bin/gl-auth-command jiangxin",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty <用户jiangxin的公钥...>
# gitolite end

5.4.2.3. 更改授权¶

新用户添加完毕，接下来需要为新用户添加授权，这个过程也比较简单，只需修改conf/gitolite.conf配置文件，提交并推送。具体操作过程如下：

1. 管理员进入gitolite-admin本地克隆版本库中，编辑conf/gitolite.conf。

   $ vi conf/gitolite.conf
   

2. 授权指令比较复杂，先通过建立新用户组尝试一下更改授权文件。

   考虑到之前增加了三个用户公钥，服务器端发出了用户尚未在授权文件中出现的警告。现在就在这个示例中解决这个问题。

   • 可以在其中加入用户组@team1，将新添加的用户jiangxin、dev1、dev2都归属到这个组中。

     只需要在conf/gitolite.conf文件的文件头加入如下指令即可。用户名之间用空格分隔。

     @team1 = dev1 dev2 jiangxin
     

   • 编辑完毕退出。可以用git diff命令查看改动：

     还修改了版本库testing的授权，将@all用户组改为新建立的@team1用户组。

     $ git diff
     diff --git a/conf/gitolite.conf b/conf/gitolite.conf
     index 6c5fdf8..f983a84 100644
     --- a/conf/gitolite.conf
     +++ b/conf/gitolite.conf
     @@ -1,5 +1,7 @@
     +@team1 = dev1 dev2 jiangxin
     +
      repo    gitolite-admin
              RW+     =   admin
     
      repo    testing
     -        RW+     =   @all
     +        RW+     =   @team1
     

3. 编辑结束，提交改动。

   $ git add conf/gitolite.conf
   $ git commit -q -m "new team @team1 auth for repo testing."
   

4. 执行git push，同步到服务器，授权文件的更改才真正生效。

   可以注意到，推送后的输出中没有了警告。

   $ git push
   Counting objects: 7, done.
   Delta compression using up to 2 threads.
   Compressing objects: 100% (3/3), done.
   Writing objects: 100% (4/4), 398 bytes, done.
   Total 4 (delta 1), reused 0 (delta 0)
   remote: Already on 'master'
   To git@server:gitolite-admin.git
      bd81884..79b29e4  master -> master
   

5.4.3.1. 授权文件的基本语法¶

下面看一个不那么简单的授权文件。为方便描述添加了行号。

 1  @manager = jiangxin wangsheng
 2  @dev   = dev1 dev2 dev3
 3
 4  repo    gitolite-admin
 5          RW+                         = jiangxin
 6
 7  repo    ossxp/[a-z].+
 8          C                           = @manager
 9          RW+                         = CREATOR
10          RW                          = WRITERS
11          R                           = READERS @dev
12
13  repo    testing
14          RW+                         =   @manager
15          RW      master              =   @dev
16          RW      refs/tags/v[0-9]    =   dev1
17          -       refs/tags/          =   @all

在上面的示例中，演示了很多授权指令：

• 第1行，定义了用户组@manager，包含两个用户jiangxin和wangsheng。
• 第2行，定义了用户组@dev，包含三个用户dev1、dev2和dev3。
• 第4-5行，定义了版本库gitolite-admin。指定只有超级用户jiangxin才能够访问，并拥有读（R）写（W）和强制更新（+）的权限。
• 第7行，通过正则表达式为一组版本库进行批量授权。即针对ossxp目录下以小写字母开头的所有版本库进行授权。
• 第8行，用户组@manager中的用户可以创建版本库。即可以在ossxp目录下创建以小写字母开头的版本库。
• 第9行，版本库的创建者拥有对所创建版本库的完全权限。版本库的创建者是通过git push命令创建版本库的那一个人。
• 第10-11行，出现了两个特殊角色WRITERS和READERS，这两个角色不在本配置文件中定义，而是由版本库创建者使用Gitolite支持的setperms命令进行设置。
• 第11行，还设置了@dev用户组的用户对ossxp目录下的版本库具有读取权限。
• 第13行开始，对testing版本库进行授权。其中使用了对引用授权的语法。
• 第14行，用户组@manager对所有引用包括分支拥有读写、重置、添加和删除的授权，但里程碑除外，因为第17行定义了一条禁用规则。
• 第15行，用户组@dev可以读写master分支。（还包括名字以master开头的其他分支，如果有的话。）
• 第16行，用户dev1可以创建里程碑（即以refs/tags/v[0-9]开始的引用）。
• 第17行，禁止所有人（@all）对以refs/tags/开头的引用进行写操作。实际上由于之前第14行和第16行建立的授权，用户组@manager的用户和用户dev1能够创建里程碑，而且用户组@manager还能删除里程碑。

下面针对授权指令进行详细的讲解。

5.4.3.2. 定义用户组和版本库组¶

在conf/gitolite.conf授权文件中，可以定义用户组或版本库组。组名称以@字符开头，可以包含一个或多个成员。成员之间用空格分开。

• 例如定义管理员组：

  @admin = jiangxin wangsheng
  

• 组可以嵌套：

  @staff = @admin @engineers tester1
  

除了作为用户组外，同样的语法也适用于版本库组。版本库组和用户组的定义没有任何区别，只是在版本库授权指令中处于不同的位置。即位于授权指令中的版本库位置代表版本库组，位于授权指令中的用户位置代表用户组。

5.4.3.3. 版本库ACL¶

一个版本库可以包含多条授权指令，这些授权指令组成了一个版本库的权限控制列表（ACL）。例如：

repo testing
    RW+                 = jiangxin @admin
    RW                  = @dev @test
    R                   = @all

repo sandbox/test1 sandbox/test2 @test_repos

repo redmine/[a-zA-Z].+

repo ossxp/.+

<权限>  [零个或多个正则表达式匹配的引用] = <user> [<user> ...]

5.4.3.4. Gitolite授权机制¶

Gitolite的授权实际分为两个阶段。第一个阶段称为前Git阶段，即在Git命令执行前，由SSH连接触发的gl-auth-command命令执行的授权检查。包括：

• 版本库的读。

  如果用户拥有版本库或版本库的任意分支具有下列权限之一：R、RW、RW+（或其他扩展关键字），则整个版本库（包含所有分支）对用户均可读，否则版本库不可读取。

  最让人迷惑的就是只为某用户分配了对某个分支的读授权（R），而该用户实际上能够读取版本库的任意分支。之所以Gitolite对读授权不能细化到分支甚至目录，只能针对版本库进行粗放的非零即壹的读操作授权，是因为读授权只在版本库授权的第一个阶段进行检查，而在此阶段还获取不到版本库的分支。

• 版本库的写。

  版本库的写授权实际上要在两个阶段分别进行检查。本阶段，即第一阶段仅检查用户是否拥有下列权限之一：RW、RW+或C授权，具有这些授权则通过第一阶段的写权限检查。第二个阶段的授权检查由Git版本库的钩子脚本触发，能够实现基于分支和路径的写操作授权，以及对分支创建、删除和是否可强制更新进行授权检查，具体见第二阶段授权过程描述。

• 版本库的创建。

  仅对正则表达式定义的通配符版本库有效。即拥有C授权的用户可以创建和相应的正则表达式匹配的版本库。创建版本库（尤其是通过执行git push命令创建版本库）不免要涉及到执行新创建的版本库的钩子脚本，所以需要为版本库设置一条创建者可读写的授权。如：

  RW = CREATOR
  

Gitolite对授权的第二个阶段的检查，实际上是通过update钩子脚本进行的。因为版本库的读操作不执行update钩子，所以读操作只在授权的第一个阶段（前Git阶段）就完成了检查，授权的第二个阶段仅对写操作进行更为精细的授权检查。

• 钩子脚本update针对推送操作的各个分支进行逐一检查，因此第二个阶段可以进行针对分支写操作的精细授权。
• 在这个阶段可以获取到要更新的新、老引用的SHA1哈希值，因此可以判断出是否发生了非快进式推送、是否有新分支创建，以及是否发生了分支的删除，因此可以针对这些操作进行精细的授权。
• 基于路径的写授权也是在这个阶段进行的。

5.4.4.1. 常规版本库授权¶

授权文件如下：

1  @admin = jiangxin
2  @dev   = dev1 dev2 badboy jiangxin
3  @test  = test1 test2
4
5  repo testing
6      RW+ = @admin
7      R = @test
8      - = badboy
9      RW = @dev test1

关于授权的说明：

• 用户jiangxin对版本库具有写的权限，并能够强制推送。

  由于用户jiangxin属于用户组@admin，通过第6行授权指令而具有读写权限，以及强制推送、创建和删除引用的权限。

• 用户test1对版本库具有写的权限。

  第7行定义了test1所属的用户组@test具有只读权限。第9行定义了test1用户具有读写权限。Gitolite的实现是对读权限和写权限分别进行判断并汇总（并集），从而test1用户具有读写权限。

• 用户badboy对版本库只具有读操作的权限，没有写操作权限。

  第8行的指令以减号（-）开始，是一条禁用指令。禁用指令只在授权的第二阶段起作用，即只对写操作起作用，不会对badboy用户的读权限施加影响。在第9行的指令中，badboy所在的@dev组拥有读写权限。但禁用规则会对写操作起作用，导致badboy只有读操作权限，而没有写操作。

上面在Gitolite配置文件中对testing版本库进行的授权，当通过推送更新至Gitolite服务器上时，如果服务器端尚不存在一个名为testing的版本库，Gitolite会自动初始化一个空白的testing版本库。

5.4.4.2. 通配符版本库授权¶

授权文件如下：

 1   @administrators = jiangxin admin
 2   @dev            = dev1 dev2 badboy
 3   @test           = test1 test2
 4
 5   repo    sandbox/[a-z].+
 6           C       = @administrators
 7           RW+     = CREATOR
 8           R       = @test
 9           -       = badboy
10           RW      = @dev test1

这个授权文件的版本库名称中使用了正则表达式，匹配在sandbox目录下的任意以小写字母开头的版本库。因为通配符版本库并非指代一个具体版本库，因而不会在服务器端自动创建，而是需要管理员手动创建。

创建和通配符匹配的版本库，Gitolite的原始实现是克隆即创建。例如管理员jiangxin创建名为sandbox/repos1.git版本库，执行下面命令：

jiangxin$ git clone git@server:sandbox/repos1.git

这种克隆即创建的方式很容易因为录入错误而导致意外创建错误的版本库。我改进的Gitolite需要通过推送来创建版本库。下面的示例通过推送操作（以jiangxin用户身份），远程创建版本库sandbox/repos1.git。

jiangxin$ git remote add origin git@server:sandbox/repos1.git
jiangxin$ git push origin master

对创建完成的sandbox/repo1.git版本库进行授权检查，会发现：

• 用户jiangxin对版本库具有读写权限，而用户admin则不能读取sandbox/repo1.git版本库。

  第6行的授权指令同时为用户jiangxin和admin赋予了创建与通配符相符的版本库的权限。但因为版本库sandbox/repo1.git是由jiangxin而非admin创建的，所以第7条的授权指令只为版本库的创建者jiangxin赋予了读写权限。

  Gitolite通过在服务器端该版本库目录下创建一个名为gl-creater的文件记录了版本库的创建者。

• 和之前的例子相同的是：

  • 用户test1对版本库具有写的权限。
  • 禁用指令让用户badboy对版本库仅具有只读权限。

如果采用接下来的示例中的版本库权限设置，版本库sandbox/repo1.git的创建者jiangxin还可以使用setperms命令为版本库添加授权。具体用法参见下面的示例。

5.4.4.3. 每个人创建自己的版本库¶

授权文件如下：

1  @administrators = jiangxin admin
2
3  repo    users/CREATOR/[a-zA-Z].*
4          C   =  @all
5          RW+ =  CREATOR
6          RW  =  WRITERS
7          R   =  READERS @administrators

关于授权的说明：

• 第4条指令，设置用户可以在自己的名字空间（/usrs/<userid>/）下，自己创建版本库。例如下面就是用户dev1执行git push命令在Gitolite服务器上自己的名字空间下创建版本库。

  dev1$ git push git@server:users/dev1/repos1.git master
  

• 第5条指令，设置版本库创建者对版本库具有完全权限。

  即用户dev1拥有对其自建的users/dev1/repos1.git拥有最高权限。

• 第7条指令，让管理员组@administrators的用户对于users/下用户自建的版本库拥有读取权限。

那么第6、7条授权指令中出现的WRITERS和READERS是如何定义的呢？实际上这两个变量可以看做是两个用户组，不过这两个用户组不是在Gitolite授权文件中设置，而是由版本库创建者执行ssh命令创建的。

版本库users/dev1/repos1.git的创建者dev1可以通过ssh命令连接服务器，使用setperms命令为自己的版本库设置角色。命令setperms的唯一一个参数就是版本库名称。当执行命令时，会自动进入一个编辑界面，手动输入角色定义后，按下^D（Ctrl+D）结束编辑。如下所示：

dev1$ ssh git@server setperms users/dev1/repos1.git
READERS dev2 dev3
WRITERS jiangxin
^D

即在输入setperms指令后，进入一个编辑界面，输入^D（Ctrl+D）结束编辑。也可以将角色定义文件保存到文件中，用setperms指令加载。如下：

dev1$ cat > perms << EOF
READERS dev2 dev3
WRITERS jiangxin
EOF

dev1$ ssh git@server setperms users/dev1/repos1.git < perms
New perms are:
READERS dev2 dev3
WRITERS jiangxin

当版本库创建者dev1对版本库users/dev1/repos1.git进行了如上设置后，Gitolite在进行授权检查时会将setperms设置的角色定义应用到授权文件中。故此版本库users/dev1/repos1.git中又补充了新的授权：

• 用户dev2和dev3具有读取权限。
• 用户jiangxin具有读写权限。

版本库users/dev1/repos1.git的建立者dev1可以使用getperms查看自己版本库的角色设置。如下：

dev1$ ssh git@server getperms users/dev1/repos1.git
READERS dev2 dev3
WRITERS jiangxin

如果在用户自定义授权中需要使用READERS和WRITERS之外的角色，管理员可以通过修改gitolite.rc文件中的变量$GL_WILDREPOS_PERM_CATS实现。该变量的默认设置如下：

$GL_WILDREPOS_PERM_CATS = "READERS WRITERS";

5.4.4.4. 传统模式的引用授权¶

传统模式的引用授权指的是在授权指令中只采用R、RW和RW+的传统授权关键字，而不包括后面介绍的扩展授权指令。传统的授权指令没有把分支的创建和分支删除权限细分，而是和写操作及强制推送操作混杂在一起。

• 非快进式推送必须拥有上述关键字中的+方可授权。
• 创建引用必须拥有上述关键字中的W方可授权。
• 删除引用必须拥有上述关键字中的+方可授权。
• 如果没有在授权指令中提供引用相关的参数，相当于提供refs/.*作为引用的参数，意味着对所有引用均有效。

授权文件：

1  @administrators = jiangxin admin
2  @dev            = dev1 dev2 badboy
3  @test           = test1 test2
4
5  repo    test/repo1
6          RW+                           = @administrators
7          RW master refs/heads/feature/ = @dev
8          R                             = @test

关于授权的说明：

• 第6行，对于版本库test/repo1，管理员组用户jiangxin和admin可以读写任意分支、强制推送，以及创建和删除引用。
• 第7行，用户组@dev除了对master和refs/heads/feature/开头的引用具有读写权限外，实际上可以读取所有引用。这是因为读取操作授权阶段无法获知引用。
• 第8行，用户组@test对版本库拥有只读授权。

5.4.4.5. 扩展模式的引用授权¶

扩展模式的引用授权，指的是该版本库的授权指令出现了下列授权关键字中的一个或多个：RWC、RWD、RWCD、RW+C、RW+D、RW+CD，将分支的创建权限和删除权限从读写权限中分离出来，从而可对分支进行更为精细的权限控制。

• 非快进式推送必须拥有上述关键字中的+方可授权。
• 创建引用必须拥有上述关键字中的C方可授权。
• 删除引用必须拥有上述关键字中的D方可授权。

即引用的创建和删除使用了单独的授权关键字，和写权限和强制推送权限分开。

下面是一个采用扩展授权关键字的授权文件：

1   repo    test/repo2
2           RW+C = @administrators
3           RW+  = @dev
4           RW   = @test
5
6   repo    test/repo3
7           RW+CD = @administrators
8           RW+C  = @dev
9           RW    = @test

通过上面的配置文件，对于版本库test/repo2.git具有如下的授权：

• 第2行，用户组@administrators中的用户，具有创建和删除引用的权限，并且能强制推送。

  其中创建引用来自授权关键字中的C，删除引用来自授权关键中的+，因为该版本库授权指令中没有出现D，因而删除应用授权沿用传统授权关键字。

• 第3行，用户组@dev中的用户，不能创建引用，但可以删除引用，并且可以强制推送。

  因为第2行授权关键字中字符C的出现，使得创建引用采用扩展授权关键字，因而用户组@dev不具有创建引用的权限。

• 第4行，用户组@test中的用户，拥有读写权限，但是不能创建引用，不能删除引用，也不能强制推送。

通过上面的配置文件，对于版本库test/repo3.git具有如下的授权：

• 第7行，用户组@administrators中的用户，具有创建和删除引用的权限，并且能强制推送。

  其中创建引用来自授权关键字中的C，删除引用来自授权关键中的D。

• 第8行，用户组@dev中的用户，可以创建引用，并能够强制推送，但不能删除引用。

  因为第7行授权关键字中字符C和D的出现，使得创建和删除引用都采用扩展授权关键字，因而用户组@dev不具有删除引用的权限。

• 第9行，用户组@test中的用户，可以推送到任何引用，但是不能创建引用，不能删除引用，也不能强制推送。

5.4.4.6. 禁用规则的使用¶

授权文件片段：

1     RW      refs/tags/v[0-9]        =   jiangxin
2     -       refs/tags/v[0-9]        =   @dev
3     RW      refs/tags/              =   @dev

关于授权的说明：

• 用户jiangxin可以创建任何里程碑，包括以v加上数字开头的版本里程碑。
• 用户组@dev，只能创建除了版本里程碑（以v加上数字开头）之外的其他里程碑。
• 其中以-开头的授权指令建立禁用规则。禁用规则只在授权的第二阶段有效，因此不能限制用户的读取权限。

5.4.4.7. 用户分支¶

前面我们介绍过通过CREATOR特殊关键字实现用户自建版本库的功能。与之类似，Gitolite还支持在一个版本库中用户自建分支的功能。

用户在版本库中自建分支用到的关键字是USER而非CREATOR。即当授权指令的引用表达式中出现的USER关键字时，在授权检查时会动态替换为用户ID。例如授权文件片段：

1   repo    test/repo4
2           RW+CD                      = @administrators
3           RW+CD refs/heads/u/USER/   = @all
4           RW+   master               = @dev

关于授权的说明：

• 第2行，用户组@administrators中的用户，对所有引用具有读写、创建和删除的权限，并且能强制推送。
• 第3行，所有用户都可以创建以u/<userid>/（含自己用户ID）开头的分支。对自己名字空间下的引用具有完全权限。对于他人名字空间的引用只有读取权限，不能修改。
• 第4行，用户组@dev对master分支具有读写和强制更新的权限，但是不能删除。

5.4.4.8. 对路径的写授权¶

Gitolite也实现了对路径的写操作的精细授权，并且非常巧妙的是实现此功能所增加的代码可以忽略不计。这是因为Gitolite把路径当作是特殊格式的引用的授权。

在授权文件中，如果一个版本库的授权指令中的正则引用字段出现了以NAME/开头的引用，则表明该授权指令是针对路径进行的写授权，并且该版本库要进行基于路径的写授权判断。

示例：

1  repo foo
2      RW                  =   @junior_devs @senior_devs
3
4      RW  NAME/           =   @senior_devs
5      -   NAME/Makefile   =   @junior_devs
6      RW  NAME/           =   @junior_devs

关于授权的说明：

• 第2行，初级程序员@junior_devs和高级程序员@senior_devs可以对版本库foo进行读写操作。
• 第4行，设定高级程序员@senior_devs对所有文件（NAME/）进行写操作。
• 第5行和第6行，设定初级程序员@junior_devs对除了根目录的Makefile文件外的其他文件具有写权限。

5.4.5.1. 在配置文件中出现的版本库，即时生成¶

尝试在授权文件conf/gitolite.conf中加入一段新的版本库授权指令，而这个版本库尚不存在。新添加到授权文件中的内容为：

repo testing2
    RW+                 = @all

然后将授权文件的修改提交并推送到服务器，会看到授权文件中添加新授权的版本库testing2被自动创建。

$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 375 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Already on 'master'
remote: creating testing2...
remote: Initialized empty Git repository in /home/git/repositories/testing2.git/
To gitadmin.bj:gitolite-admin.git
   278e54b..b6f05c1  master -> master

注意其中带remote标识的输出，可以看到版本库testing2.git被自动初始化了。

此外使用版本库组的语法（即用@创建的组，用作版本库），也会被自动创建。例如下面的授权文件片段设定了一个包含两个版本库的组@testing，当将新配置文件推送到服务器上时，会自动创建testing3.git和testing4.git。

@testing = testing3 testing4

repo @testing
    RW+                 = @all

5.4.5.2. 通配符版本库，管理员通过推送创建¶

通配符版本库是用正则表达式语法定义的版本库，所指的并非某一个版本库而是和正则表达式相匹配的一组版本库。要想使用通配符版本库，需要在服务器端Gitolite的安装用户（如git）主目录下，修改配置文件.gitolite.rc，使其包含如下配置：

$GL_WILDREPOS = 1;

使用通配符版本库，可以对一组版本库进行授权，非常有效。但是版本库的创建则不像前面介绍的那样，不会在授权文件推送到服务器时创建，而是由拥有版本库创建授权（C）的用户手工进行创建。

对于用通配符设置的版本库，用C指令指定能够创建此版本库的管理员（拥有创建版本库的授权）。例如：

repo ossxp/[a-z].+
    C                   = jiangxin
    RW                  = dev1 dev2

用户jinagxin可以创建路径符合正则表达式ossxp/[a-z].+的版本库，用户dev1和dev2对版本库具有读写（但是没有强制更新）权限。

• 本地建库。

  $ mkdir somerepo
  $ cd somerepo
  $ git init
  $ git commit --allow-empty
  

• 使用git remote指令设置远程版本库。

  jiangxin$ git remote add origin git@server:ossxp/somerepo.git
  

• 运行git push完成在服务器端版本库的创建。

  jiangxin$ git push origin master
  

使用该方法创建版本库后，创建者jiangxin的用户ID将被记录在版本库目录下的gl-creater文件中。该帐号具有对该版本库最高的权限。该通配符版本库的授权指令中如果出现关键字CREATOR将会用创建者的用户ID替换。

实际上Gitolite的原始实现是通过克隆即可创建版本库。即当克隆一个不存在的、名称匹配通配符版本库的、且拥有创建权限（C），Gitolite会自动在服务器端创建该版本库。但是我认为这不是一个好的实践，会经常因为在克隆时把URL写错，从而导致在服务器端创建垃圾版本库。因此我重新改造了Gitolite通配符版本库创建的实现方法，使用推送操作实现版本库的创建，而克隆一个不存在的版本库会报错、退出。

5.4.5.3. 向Gitolite中导入版本库¶

在Gitolite搭建时，已经存在并使用的版本库需要导入到Gitolite中。如果只是简单地把这些裸版本库（以.git为后缀不带工作区的版本库）复制到Gitolite的版本库根目录下，针对这些版本库的授权可能不能正常工作。这是因为Gitolite管理的版本库都配置了特定的钩子脚本，以实现基于分支和/或路径的授权，直接拷贝到Gitolite中的版本库没有正确地设置钩子脚本。而且Gitolite还利用版本库中的gl-creater记录版本库创建者，用gl-perms记录版本库的自定义授权，而这些也是拷贝过来的版本库不具备的。

对于少量的版本库，直接修修改gitolite-admin的授权文件、添加同名的版本库授权、提交并推送，就会在Gitolite服务器端完成同名版本库的初始化。然后在客户端进入到相应版本库的工作区，执行git push命令将原有版本库的各个分支和里程碑导入到Gitolite新建的版本库中。

$ git remote add origin git@server:<repo-name>.git
$ git push --all  origin
$ git push --tags origin

如果要导入的版本库较多，逐一在客户端执行git push操作很繁琐。可以采用下面的方法。

• 确认要导入所有版本库都以裸版本库形式存在（以.git为后缀，无工作区）。
• 将要导入的裸版本库复制到Gitolite服务器的版本库根目录中。
• 在客户端修改gitolite-admin授权文件，为每个导入的版本库添加授权。
• 推送对gitolite-admin版本库的修改，相应版本库的钩子脚本会自动进行设置。

如果版本库非常多，就连在gitolite-admin的授权文件中添加版本库授权也是难事，还可以采用下面的办法：

• 确认要导入所有版本库都以裸版本库形式存在（以.git为后缀，无工作区）。
• 将要导入的裸版本库复制到Gitolite服务器的版本库根目录中。
• 在服务器端，为每个导入的裸版本库下添加文件gl-creater，内容为版本库创建者ID。
• 在服务器端运行gl-setup程序（无需提供公钥参数），参见Gitolite安装相应章节。
• 在客户端修改gitolite-admin授权文件，以通配符版本库形式为导入的版本库进行授权。

5.4.7.1. 版本库镜像¶

Git版本库控制系统往往并不需要设计特别的容灾备份，因为每一个Git用户就是一个备份。但是下面的情况，就很有必要考虑容灾了。

• Git版本库的使用者很少（每个库可能只有一个用户）。
• 版本库克隆只限制在办公区并且服务器也在办公区内（所有鸡蛋都在一个篮子里）。
• Git版本库采用集中式的应用模型，需要建立双机热备（以便在故障出现时，实现快速的服务器切换）。

可以在两台或多台安装了Gitolite服务的服务器之间实现版本库的镜像。数据镜像的最小单位为版本库，对于任意一个Git版本库可以选择在其中一个服务器上建立主版本库（只能有一个主版本库），在其他服务器上建立的为镜像库。镜像库只接受来自主版本库的数据同步而不接受来自用户的推送。

$GL_HOSTNAME = 'serer1';
$GL_GITCONFIG_KEYS = "gitolite.mirror.*";

$ sudo su - git
$ ssh-keygen

$ gl-tool add-mirroring-peer server2.pub

$ ssh git@server2 info
Hello server1, I am server2

repo    testing
        config gitolite.mirror.master = "server1"
        config gitolite.mirror.slaves = "server2"

[gitolite "mirror"]
        master = server1
        slaves = server2

$ git push git@server1:testing.git master
[master c0b097a] test
Counting objects: 1, done.
Writing objects: 100% (1/1), 185 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: (29781&) server1 ==== (testing) ===> server2
To git@server1:testing.git
   d222699..c0b097a  master -> master

repo   @all
    config gitolite.mirror.master = "server1"
    config gitolite.mirror.slaves = "server2"

$ gl-mirror-shell request-push gitolite-admin

5.4.7.2. Gitweb和Git daemon支持¶

Gitolite和git-daemon的整合很简单，就是由Gitolite创建的版本库会在版本库目录中创建一个空文件git-daemon-export-ok。

Gitolite和Gitweb的整合则提供了两个方面的内容。一个是可以设置版本库的描述信息，用于在Gitweb的项目列表页面中显示。另外一个是自动生成项目的列表文件供Gitweb参考，避免Gitweb使用低效率的目录递归搜索查找Git版本库列表。

可以在授权文件中设定版本库的描述信息，并在gitolite-admin管理库更新时创建到版本库的description文件中。

reponame = "one line of description"
reponame "owner name" = "one line of description"

• 第1行，为名为reponame的版本库设定描述。
• 第2行，同时设定版本库的属主名称，以及一行版本库描述。

对于通配符版本库，使用这种方法则很不现实。Gitolite提供了SSH子命令供版本库的创建者使用。

$ ssh git@server setdesc path/to/repos.git
$ ssh git@server getdesc path/to/repos.git

• 第一条指令用于设置版本库的描述信息。
• 第二条指令显示版本库的描述信息。

至于生成Gitweb所用的项目列表文件，默认创建在用户主目录下的projects.list文件中。对于所有启用Gitweb的[repo]小节所设定的版本库，以及通过版本库描述隐式声明的版本库都会加入到版本库列表中。

5.4.7.3. 其他功能拓展和参考¶

Gitolite源码的doc目录包含用markdown标记语言编写的手册，可以直接在Github上查看。也可以使用markdown的文档编辑工具将.mkd文档转换为 html 文档。转换工具很多，有rdiscount、Bluefeather、Maruku、BlueCloth2，等等。

在这些参考文档中，用户可以发现Gitolite包含的更多的小功能或秘籍，包括：

• 版本库设置。

  授权文件通过git config指令为版本库进行附加的设置。例如：

  repo gitolite
      config hooks.mailinglist = gitolite-commits@example.tld
      config hooks.emailprefix = "[gitolite] "
      config foo.bar = ""
      config foo.baz =
  

• 多级管理员授权。

  可以为不同的版本库设定管理员，操作gitolite-admin库的部分授权文件。具体参考：doc/5-delegation.mkd。

• 自定义钩子脚本。

  因为Gitolite占用了几个钩子脚本，如果需要对同名钩子进行扩展，Gitolite提供了级联的钩子脚本，将定制放在级联的钩子脚本里。

  例如：通过自定义gitolite-admin的post-update.secondary脚本，以实现无须登录服务器即可更改.gitolite.rc文件。具体参考：doc/shell-games.mkd。

  关于钩子脚本的创建和维护，具体参考：doc/hook-propagation.mkd。

• 管理员自定义命令。

  通过设置配置文件中的$GL_ADC_PATH变量，在远程执行该目录下的可执行脚本，如：rmrepo。

  具体参考：doc/admin-defined-commands.mkd。

• 创建匿名的SSH认证。

  允许匿名用户访问Gitolite提供的Git服务。即建立一个和Gitolite服务器端帐号同ID同主目录的用户，设置其的特定shell，并且允许口令为空。

  具体参考：doc/mob-branches.mkd。

• 可以通过名为@all的版本库进行全局的授权。

  但是不能在@all版本库中对@all用户组进行授权。

• 版本库或用户非常之多（几千个）的时候，需要使用大配置文件模式。

  因为Gitolite的授权文件要先编译才能生效，而编译文件的大小是和用户及版本库数量的乘积成正比的。选择大配置文件模式则不对用户组和版本库组进行扩展。

  具体参考：doc/big-config.mkd。

• 授权文件支持包含语句，可以将授权文件分成多个独立的单元。

• 执行外部命令，如rsync。

• Subversion版本库支持。

  如果在同一个服务器上以svn+ssh方式运行Subversion服务器，可以使用同一套公钥，同时为用户提供Git和Subversion服务。

• HTTP口令文件维护。通过名为htpasswd的SSH子命令实现。