30.3.4　Gitolite授权机制

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

版本库的读。

如果用户拥有版本库（或至少一个分支）的下列权限之一：R、RW或RW+，则整个版本库（包含所有分支）对用户均可读。

实际上为用户设置某个分支的R权限的含义并非其他分支不可读，而是此分支不可写。之所以Gitolite对读授权不能细化到分支甚至目录，只能粗放地对整个版本库进行读授权，是因为读授权只在版本库授权的第一个阶段进行检查，而在此阶段还获取不到版本库的分支。

版本库的写。

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

版本库的创建。

仅对正则表达式定义的通配符版本库有效。即拥有C授权的用户可以创建和对应正则表达式匹配的版本库。同时该用户也拥有对版本库的读写权限。

Gitolite对授权的第二个阶段的检查，实际上是通过update钩子脚本进行的。

因为版本库的读操作不执行update钩子，所以读操作只在授权的第一个阶段（前Git阶段）就完成了检查，授权的第二个阶段对版本库的读授权无任何影响。

钩子脚本update针对推送操作的各个分支进行逐一检查，因此第二个阶段可以进行针对分支写操作的精细授权。

在这个阶段可以获取到要更新的新、老引用的SHA1哈希值，因此可以判断出是否发生了非快进式推送、是否有新分支创建，以及是否发生了分支的删除，因此可以针对这些操作进行精细的授权。

基于路径的写授权也是在这个阶段进行的。