使用 Gitolite 搭建 Git 服务器

Gitolite 是在 Git 之上的一个授权层，依托 sshd 或者 httpd 来进行认证。（认证是确定用户是谁，授权是决定该用户是否被允许做他想做的事情）。

通过 Gitolite 你可以设置访问权限，不只作用于仓库，还可以作用到每个 branch 和 tag name。你可以定义确切的人(或一组人)只能 push 特定的 "refs" (或者 branches 或者 tags )。

写在前面

如果你熟悉 Git 和 SVN 的区别，相信你不会认为 Git 服务器有多复杂。而事实上，搭建一个无需授权管理的Git服务器确实很简单。因为这个服务器仅仅是一个远程裸仓库（无工作区），用来作为24小时开机的交换中心而已。如果你的需求如此简单，推荐学习 廖雪峰 《Git 教程》中的 搭建 Git 服务器 一节。

如果你还没离开，那接下来，我们聊聊 Git 的权限管理这点事儿。Git 本身是不支持权限控制的，可能它也不想这么做。由于 Git 支持钩子（hook），因此可以在服务器端编写一系列脚本来控制 Git 的各种操作，达到权限控制的目的。

Gitolite 只是 Git 权限管理工具中的一种，具有同样功能的还有：

• GitLab 可以说是 GitHub 的开源版本，一开始是使用 Gitolite 作为授权管理的解决方案，后来因为两个项目的开发和同步等方面出现问题，在2013年2月，GitLab 宣布与 Gitolite 分道扬镳。总之，GitLab 是一个重量级的版本，要使用它，你需要安装很多额外的软件，如 PostgreSQL, Redis, Sidekiq, Unicorn, nginx and gitlab-shell 等。所以说，它是资源密集型的，但功能确实强大，也更有利于开发团队的高效率协作，比较适合大型团队。

• Gitosis 和 Gitolite 没什么区别，只是这个项目已经停止维护了，所以我也懒得去费时间进行了解，这里只是提一下。

• 其他 肯定会有其他的解决方案，只是我觉得知道以上的就足够了。

简单介绍

到现在我们也只是知道，Gitolite 是一款 Git 授权管理工具，那么它具体是怎样的呢？我们姑且从它的几个特性来简单了解下：

• 在服务器端，使用一个 unix 用户作为远程访问的对象

• 为多用户提供访问权限，但他们不是真正的用户，不会获得 shell 权限

• 控制对多个 git 仓库的访问，读访问被repo层控制，写访问在 branch/tag/file/directory 层控制，包括谁能够 rewind，create 以及 delete branches/tags

• 能够不经过root允许进行安装，假设git和perl已经被安装了 （这句话不懂，暂时直译过来）？

• 认证通常采用sshd，但是也可以使用httpd

• 能够简化你的仓库路径，类似 GitHub 那样，例如：git@your_server.com:your-project.git

开始搭建

1. （服务端） 切换到 root 身份

   `su - root`
   

2. （服务端） 安装依赖

   `apt-get install git-core ssh`
   

3. （服务端） 创建一个用户供 Gitolite 使用：

   `useradd --system --shell /bin/bash --create-home git`
   

4. （服务端） 设置密码

   `passwd git`
   

5. （客户端） 生成 SSH 公钥并复制到服务器的 git 家目录

   `cd ~`  
   
   `ssh-keygen`  
   
   `scp ~/.ssh/id_rsa.pub git@your_server:admin.pub`
   

6. （服务端） 安装 Gitolite

   `su - git`
   
   `mkdir bin`
   
   `git clone git://github.com/sitaramc/gitolite.git`
   
   `~/gitolite/install -to ~/bin`
   
   \# 将你的公钥 admin.php 设置为 Gitolite 超级管理员  
   `~/bin/gitolite setup -pk ~/admin.pub` 
   

7. （客户端） 克隆神奇的授权管理仓库

   \# 如果克隆成功，说明 Git 服务器已经搭建完成。  
   `git clone git@your_server:gitolite-admin` 
   
   

使用方法

1. 添加 Gitolite 项目成员

   将项目成员通过 ssh-keygen 命令生成的公钥文件重命名成唯一标识的文件，如macken.pub，然后放到 gitolite-admin/keydir 目录下，add、commit、push之后，这样新成员就算加入了。新成员默认可以克隆任何没有被权限控制的仓库，如 Gitolite 自带的 "testing"。

2. 创建 Gitolite 项目仓库

   仓库的创建不需要你登录服务端，只需要用编辑器打开 gitolite-admin/conf/gitolite.conf，加入两行：

   repo new_repo

   RW = macken

   然后将变动提交到服务器，远程的 Gitolite 就会自动帮你创建好一个空仓库并分配给 macken 读写的权限。是不是很方便？

3. 项目授权管理

   • 要方便的进行授权，那就有必要将项目的成员分组：

     @admins = macken steven

     @interns = ashok

     @engineers = macken steven wally alice

     @staff = @admins @engineers

   • 可以对仓库的分支和标签进行正则匹配授权：

     repo @oss_repos

     RW int$ = @interns

     RW eng- = @engineers

     RW refs/tags/rc[0-9] = @engineers

     RW+ = @admins

     interns 组只能对以 “int“ 结尾的分支有读写权限；

     engineers 组可以对以 “eng-“ 开头的分支以及该仓库的 “rc[0-9]“ 的标签分支有读写权限；

     admins 组则对本仓库所有的分支有读写权限，而且 “+” 代表可以有强推的权限。

     其它更详尽的授权设置请参阅 官方文档

写在最后

Git 是极具开源精神的分布式版本控制系统，但并不意味着在 Git 基础上加上授权控制是有什么不妥，目的不在于防着谁，而在于明确职责划分，方便协调管理，避免因为任何人都可以接触所有代码而产生不必要的麻烦。就像 GitHub 那样，任何人都可以 fork 别人的项目，从而生成一个分支到自己的仓库，但你无法直接操作别人的 master 分支，只能由项目的创建者根据你提交的 PR 来进行 merge。这样，才是一个有秩序的开源实践。

最后，推荐一篇关于 Git Workflow 的经典老文：A successful Git branching model。

原文链接： https://macken.me/article/use...