使用 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 目录下,addcommitpush之后,这样新成员就算加入了。新成员默认可以克隆任何没有被权限控制的仓库,如 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...

相关推荐