使用 Gitolite 搭建 Git 服务器 gitgitolite

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

开始搭建

（服务端）切换到 root 身份

`su - root`
（服务端）安装依赖

`apt-get install git-core ssh`
（服务端）创建一个用户供 Gitolite 使用：

`useradd --system --shell /bin/bash --create-home git`
（服务端）设置密码

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

`cd ~``ssh-keygen``scp ~/.ssh/id_rsa.pub git@your_server:admin.pub`
（服务端）安装 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`
（客户端）克隆神奇的授权管理仓库

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

使用方法

添加 Gitolite 项目成员
将项目成员通过 ssh-keygen 命令生成的公钥文件重命名成唯一标识的文件，如macken.pub，然后放到 gitolite-admin/keydir 目录下，add、commit、push之后，这样新成员就算加入了。新成员默认可以克隆任何没有被权限控制的仓库，如 Gitolite 自带的 "testing"。
创建 Gitolite 项目仓库
仓库的创建不需要你登录服务端，只需要用编辑器打开 gitolite-admin/conf/gitolite.conf，加入两行：
repo new_repo
RW = macken
然后将变动提交到服务器，远程的 Gitolite 就会自动帮你创建好一个空仓库并分配给 macken 读写的权限。是不是很方便？
项目授权管理
- 要方便的进行授权，那就有必要将项目的成员分组：
  @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。
【使用 Gitolite 搭建 Git 服务器】原文链接： https://macken.me/article/use...