使用 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...