使用 Git 来管理 Git 服务器

借助 Gitolite，你可使用 Git 来管理 Git 服务器。在咱们的系列文章中了解这些不为人知的 Git 用途。

正如我在系列文章中演示的那样，Git 除了跟踪源代码外，还能够作不少事情。信不信由你，Git 甚至能够管理你的 Git 服务器，所以你能够或多或少地使用 Git 自己来运行 Git 服务器。

固然，这涉及除平常使用 Git 以外的许多组件，其中最重要的是 Gitolite，该后端应用程序能够管理你使用 Git 的每一个细微的配置。Gitolite 的优势在于，因为它使用 Git 做为其前端接口，所以很容易将 Git 服务器管理集成到其余基于 Git 的工做流中。Gitolite 能够精确控制谁能够访问你服务器上的特定存储库以及他们具备哪些权限。你可使用常规的 Linux 系统工具自行管理此类事务，可是若是有好几个用户和不止一两个仓库，则须要大量的工做。

Gitolite 的开发人员作了艰苦的工做，使你能够轻松地为许多用户提供对你的 Git 服务器的访问权，而又不让他们访问你的整个环境 —— 而这一切，你可使用 Git 来完成所有工做。

Gitolite 并不是图形化的管理员和用户面板。优秀的 Gitea 项目可提供这种体验，可是本文重点介绍 Gitolite 的简单优雅和使人温馨的熟悉感。

安装 Gitolite

假设你的 Git 服务器运行在 Linux 上，则可使用包管理器安装 Gitolite（在 CentOS 和 RHEL 上为 yum，在 Debian 和 Ubuntu 上为 apt，在 OpenSUSE 上为 zypper 等）。例如，在 RHEL 上：

$ sudo yum install gitolite3
复制代码

许多发行版的存储库提供的还是旧版本的 Gitolite，但最新版本为版本 3。

你必须具备对服务器的无密码 SSH 访问权限。若是愿意，你可使用密码登陆服务器，可是 Gitolite 依赖于 SSH 密钥，所以必须配置使用密钥登陆的选项。若是你不知道如何配置服务器以进行无密码 SSH 访问，请首先学习如何进行操做（Steve Ovens 的 Ansible 文章的设置 SSH 密钥身份验证部分对此进行了很好的说明）。这是增强服务器管理的安全以及运行 Gitolite 的重要组成部分。

配置 Git 用户

若是没有 Gitolite，则若是某人请求访问你在服务器上托管的 Git 存储库时，则必须向该人提供用户账户。Git 提供了一个特殊的外壳，即 git-shell，这是一个仅执行 Git 任务的特别的特定 shell。这可让你有个只能经过很是受限的 Shell 环境来过滤访问你的服务器的用户。

这个解决方案是一个办法，但一般意味着用户能够访问服务器上的全部存储库，除非你具备用于组权限的良好模式，并在建立新存储库时严格遵循这些权限。这种方式还须要在系统级别进行大量手动配置，这一般是只有特定级别的系统管理员才能作的工做，而不必定是一般负责 Git 存储库的人员。

Gitolite 经过为须要访问任何存储库的每一个人指定一个用户名来彻底回避此问题。默认状况下，该用户名是 git，而且因为 Gitolite 的文档中假定使用的是它，所以在学习该工具时保留它是一个很好的默认设置。对于曾经使用过 GitLab 或 GitHub 或任何其余 Git 托管服务的人来讲，这也是一个众所周知的约定。

Gitolite 将此用户称为托管用户。在服务器上建立一个账户以充当托管用户（我习惯使用 git，由于这是惯例）：

$ sudo adduser --create-home git
复制代码

为了控制该 git 用户账户，该账户必须具备属于你的有效 SSH 公钥。你应该已经进行了设置，所以复制你的公钥（而不是你的私钥）添加到 git 用户的家目录中：

$ sudo cp ~/.ssh/id_ed25519.pub /home/git/
$ sudo chown git:git /home/git/id_ed25519.pub
复制代码

若是你的公钥不以扩展名 .pub 结尾，则 Gitolite 不会使用它，所以请相应地重命名该文件。切换为该用户账户以运行 Gitolite 的安装程序：

$ sudo su - git
$ gitolite setup --pubkey id_ed25519.pub
复制代码

安装脚本运行后，git 的家用户目录将有一个 repository 目录，该目录（目前）包含存储库 git-admin.git 和 testing.git。这就是该服务器所需的所有设置，如今请登出 git 用户。

使用 Gitolite

管理 Gitolite 就是编辑 Git 存储库中的文本文件，尤为是 gitolite-admin.git 中的。你不会经过 SSH 进入服务器来进行 Git 管理，而且 Gitolite 也建议你不要这样尝试。在 Gitolite 服务器上存储你和你的用户的存储库是个裸存储库，所以最好不要使用它们。

$ git clone git@example.com:gitolite-admin.git gitolite-admin.git
$ cd gitolite-admin.git
$ ls -1
conf
keydir
复制代码

该存储库中的 conf 目录包含一个名为 gitolite.conf 的文件。在文本编辑器中打开它，或使用 cat 查看其内容：

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all
复制代码

你可能对该配置文件的功能有所了解：gitolite-admin 表明此存储库，而且 id_ed25519 密钥的全部者具备读取、写入和管理 Git 的权限。换句话说，不是将用户映射到普通的本地 Unix 用户（由于全部用户都使用 git 用户托管用户身份），而是将用户映射到 keydir 目录中列出的 SSH 密钥。

testing.git 存储库使用特殊组符号为访问服务器的每一个人提供了所有权限。

添加用户

若是要向 Git 服务器添加一个名为 alice 的用户，Alice 必须向你发送她的 SSH 公钥。Gitolite 使用文件名的 .pub 扩展名左边的任何内容做为该 Git 用户的标识符。不要使用默认的密钥名称值，而是给密钥指定一个指示密钥全部者的名称。若是用户有多个密钥（例如，一个用于笔记本电脑，一个用于台式机），则可使用子目录来避免文件名冲突。例如，Alice 在笔记本电脑上使用的密钥多是默认的 id_rsa.pub，所以将其重命名为alice.pub 或相似名称（或让用户根据其计算机上的本地用户账户来命名密钥），而后将其放入 gitolite-admin.git/keydir/work/laptop/ 目录中。若是她从她的桌面计算机发送了另外一个密钥，命名为 alice.pub（与上一个相同），而后将其添加到 keydir/home/desktop/ 中。另外一个密钥可能放到 keydir/home/desktop/ 中，依此类推。Gitolite 递归地在 keydir 中搜索与存储库“用户”相匹配的 .pub 文件，并将全部匹配项视为相同的身份。

当你将密钥添加到 keydir 目录时，必须将它们提交回服务器。这是一件很容易忘记的事情，这里有一个使用自动化的 Git 应用程序（例如 Sparkleshare）的真正的理由，所以任何更改都将当即提交给你的 Gitolite 管理员。第一次忘记提交和推送，在浪费了三个小时的你和你的用户的故障排除时间以后，你会发现 Gitolite 是使用 Sparkleshare 的完美理由。

$ git add keydir
$ git commit -m 'added alice-laptop-0.pub'
$ git push origin HEAD
复制代码

默认状况下，Alice 能够访问 testing.git 目录，所以她可使用该目录测试链接性和功能。

设置权限

与用户同样，目录权限和组也是从你可能习惯的的常规 Unix 工具中抽象出来的（或可从在线信息查找）。在 gitolite-admin.git/conf 目录中的 gitolite.conf 文件中授予对项目的权限。权限分为四个级别：

• R 容许只读。在存储库上具备 R 权限的用户能够克隆它，仅此而已。
• RW 容许用户执行分支的快进推送、建立新分支和建立新标签。对于大多数用户来讲，这个基本上就像是一个“普通”的 Git 存储库。
• RW+ 容许可能具备破坏性的 Git 动做。用户能够执行常规的快进推送、回滚推送、变基以及删除分支和标签。你可能想要或不但愿将其授予项目中的全部贡献者。
• - 明确拒绝访问存储库。这与未在存储库的配置中列出的用户相同。

经过调整 gitolite.conf 来建立一个新的存储库或修改现有存储库的权限。例如，授予 Alice 权限来管理一个名为 widgets.git 的新存储库：

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo widgets
    RW+     =   alice
复制代码

如今，Alice（也仅有 Alice 一我的）能够克隆该存储库：

[alice]$ git clone git@example.com:widgets.git
Cloning into 'widgets'...
warning: You appear to have cloned an empty repository.
复制代码

在第一次推送时，Alice 必须使用 -u 选项将其分支发送到空存储库（如同她在任何 Git 主机上作的同样）。

为了简化用户管理，你能够定义存储库组：

@qtrepo = widgets
@qtrepo = games

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo @qtrepo
    RW+     =   alice
复制代码

正如你能够建立组存储库同样，你也能够对用户进行分组。默认状况下存在一个用户组：@all。如你所料，它包括全部用户，无一例外。你也能够建立本身的组：

@qtrepo = widgets
@qtrepo = games

@developers = alice bob

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo @qtrepo
    RW+     =   @developers
复制代码

与添加或修改密钥文件同样，对 gitolite.conf 文件的任何更改都必须提交并推送以生效。

建立存储库

默认状况下，Gitolite 假设存储库的建立是从上至下进行。例如，有权访问 Git 服务器的项目经理建立了一个项目存储库，并经过 Gitolite 管理仓库添加了开发人员。

实际上，你可能更愿意向用户授予建立存储库的权限。Gitolite 称这些为“野生仓库（通配仓库）wild repos”（我不肯定这是关于仓库的造成方式的描述，仍是指配置文件所需的通配符）。这是一个例子：

@managers = alice bob

repo foo/CREATOR/[a-z]..*
    C   =   @managers
    RW+ =   CREATOR
    RW  =   WRITERS
    R   =   READERS
复制代码

第一行定义了一组用户：该组称为 @managers，其中包含用户 alice 和 bob。下一行设置了通配符容许建立尚不存在的存储库，放在名为 foo 的目录下的建立该存储库的用户名的子目录中。例如：

[alice]$ git clone git@example.com:foo/alice/cool-app.git
Cloning into cool-app'... Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git warning: You appear to have cloned an empty repository. 复制代码

野生仓库的建立者可使用一些机制来定义谁能够读取和写入其存储库，可是他们是有范围限定的。在大多数状况下，Gitolite 假定由一组特定的用户来管理项目权限。一种解决方案是使用 Git 挂钩来授予全部用户对 gitolite-admin 的访问权限，以要求管理者批准将更改合并到 master 分支中。

了解更多

Gitolite 具备比此介绍性文章所涵盖的更多功能，所以请尝试一下。其文档很是出色，一旦你通读了它，就能够自定义 Gitolite 服务器，以向用户提供你喜欢的任何级别的控制。Gitolite 是一种维护成本低、简单的系统，你能够安装、设置它，而后基本上就能够将其忘却。

---

via: opensource.com/article/19/…

做者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出