如何构建你自己的 Git 服务器

阅读

• 第 1 部分：什么是 Git？
• 第 2 部分：Git 入门
• 第 3 部分：创建你的第一个 Git 仓库
• 第 4 部分：如何在 Git 中恢复旧版本文件
• 第 5 部分：3 个 Git 图形化工具
• 第 6 部分：如何构建你自己的 Git 服务器
• 第 7 部分：如何使用 Git 管理二进制大对象

现在我们将学习如何构建 Git 服务器，以及如何编写自定义 Git 钩子，以便在特定事件（例如通知）上触发特定操作，以及将你的代码发布到网站。

到目前为止，重点一直是作为用户与 Git 交互。在本文中，我将讨论 Git 的管理以及灵活的 Git 基础设施的设计。你可能会认为这听起来像是“高级 Git 技术”或“只有超级书呆子才读这个”的委婉说法，但实际上，这些任务都不需要高级知识或任何超出对 Git 工作原理的中级理解的特殊培训，并且在某些情况下只需要一点关于 Linux 的知识。

共享 Git 服务器

创建你自己的共享 Git 服务器非常简单，并且在许多情况下都非常值得。它不仅确保你始终可以访问你的代码，而且还为使用 Git 扩展打开了大门，例如个人 Git 钩子、无限数据存储以及持续集成和部署。

如果你知道如何使用 Git 和 SSH，那么你已经知道如何创建 Git 服务器。Git 的设计方式是，当你创建或克隆仓库的那一刻，你已经设置了一半的服务器。然后启用对仓库的 SSH 访问，任何有权访问的人都可以使用你的仓库作为新克隆的基础。

然而，这有点临时。通过一些规划，你可以构建一个设计良好的 Git 服务器，工作量大致相同，但可扩展性更好。

首先：确定你的用户，包括当前用户和未来用户。如果你是唯一的用户，则无需进行任何更改，但如果你打算邀请贡献者加入，那么你应该为你的开发人员预留一个专用的共享系统用户。

假设你有一个可用的服务器（如果没有，这不是 Git 可以解决的问题，但 Raspberry Pi 3 上的 CentOS 是一个不错的开始），那么第一步是仅使用 SSH 密钥授权启用 SSH 登录。这比密码登录强大得多，因为它对暴力攻击免疫，并且禁用用户就像删除他们的密钥一样简单。

启用 SSH 密钥授权后，创建 gituser。这是所有授权用户的共享用户

$ su -c 'adduser gituser'

然后切换到该用户，并使用适当的权限创建一个 ~/.ssh 框架。这很重要，因为为了你自己的保护，如果你设置的权限过于宽松，SSH 将默认失败。

$ su - gituser
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys

authorized_keys 文件保存了你授予 Git 项目工作权限的所有开发人员的 SSH 公钥。你的开发人员必须创建自己的 SSH 密钥对并将他们的公钥发送给你。将公钥复制到 gituser 的 authorized_keys 文件中。例如，对于名为 Bob 的开发人员，运行以下命令

$ cat ~/path/to/id_rsa.bob.pub >> \ 
/home/gituser/.ssh/authorized_keys

只要开发人员 Bob 拥有与他发送给你的公钥匹配的私钥，Bob 就可以作为 gituser 访问服务器。

但是，你实际上并不想让你的开发人员访问你的服务器，即使只是作为 gituser。你只想让他们访问 Git 仓库。正是出于这个原因，Git 提供了一个有限的 shell，适当地称为 git-shell。以 root 身份运行以下命令将 git-shell 添加到你的系统，然后将其设置为 gituser 的默认 shell

# grep git-shell /etc/shells || su -c \
"echo `which git-shell` >> /etc/shells"
# su -c 'usermod -s git-shell gituser'

现在 gituser 只能使用 SSH 推送和拉取 Git 仓库，而不能访问登录 shell。你应该将自己添加到 gituser 的相应组中，在我们的示例服务器中，该组也是 gituser。

例如

# usermod -a -G gituser seth

剩下的唯一步骤是创建一个 Git 仓库。由于没有人会直接在服务器上与它交互（也就是说，你不会 SSH 到服务器并在该仓库中直接工作），因此将其设为裸仓库。如果你想在服务器上使用该仓库来完成工作，你将从它所在的位置克隆它，并在你的主目录中工作。

严格来说，你不必将其设为裸仓库；它可以作为普通仓库工作。但是，裸仓库没有 *工作树*（也就是说，任何分支都永远不会处于 `checkout` 状态）。这很重要，因为不允许远程用户推送到活动分支（如果你正在 `dev` 分支中工作，突然有人将更改推送到你的工作区，你感觉如何？）。由于裸仓库不能有活动分支，因此永远不会出现问题。

你可以将此仓库放置在你喜欢的任何位置，只要你想授予访问权限的用户和组可以这样做即可。例如，你不想将目录存储在用户的主目录中，因为那里的权限非常严格，而是在常见的共享位置，例如 /opt 或 /usr/local/share。

以 root 身份创建裸仓库

# git init --bare /opt/jupiter.git
# chown -R gituser:gituser /opt/jupiter.git
# chmod -R 770 /opt/jupiter.git

现在，任何通过 gituser 身份验证或属于 gituser 组的用户都可以读取和写入 jupiter.git 仓库。在本地机器上试用一下

$ git clone gituser@example.com:/opt/jupiter.git jupiter.clone
Cloning into 'jupiter.clone'...
Warning: you appear to have cloned an empty repository.

请记住：开发人员必须将其公共 SSH 密钥输入到 gituser 的 authorized_keys 文件中，或者如果他们在服务器上拥有帐户（就像你一样），那么他们必须是 gituser 组的成员。

Git 钩子

运行你自己的 Git 服务器的一个好处是它可以使 Git 钩子可用。Git 托管服务有时会提供类似钩子的界面，但它们不会为你提供真正可以访问文件系统的 Git 钩子。Git 钩子是一个脚本，它在 Git 进程的某个时刻执行；钩子可以在仓库即将接收提交时、在它接受提交后、在它接收推送之前或推送之后等等执行。

这是一个简单的系统：任何放置在 .git/hooks 目录中，使用标准命名方案的可执行脚本，都会在指定的时间执行。脚本应该何时执行由名称决定；pre-push 脚本在推送之前执行，post-receive 脚本在收到提交后执行，依此类推。它或多或少是不言自明的。

脚本可以用任何语言编写；如果你的系统可以执行某种语言的 hello world 脚本，那么你可以使用该语言编写 Git 钩子脚本。默认情况下，Git 附带一些示例，但没有任何启用。

想看一个实际的例子吗？入门很容易。首先，如果你还没有 Git 仓库，请创建一个

$ mkdir jupiter
$ cd jupiter
$ git init .

然后编写一个“hello world”Git 钩子。由于我在工作中为了遗留支持而使用 tcsh，因此我将继续使用它作为我的脚本语言，但你可以随意使用你喜欢的语言（Bash、Python、Ruby、Perl、Rust、Swift、Go）代替。

$ echo "#\!/bin/tcsh" > .git/hooks/post-commit
$ echo "echo 'POST-COMMIT SCRIPT TRIGGERED'" >> \
~/jupiter/.git/hooks/post-commit
$ chmod +x ~/jupiter/.git/hooks/post-commit

现在测试一下

$ echo "hello world" > foo.txt
$ git add foo.txt
$ git commit -m 'first commit'
! POST-COMMIT SCRIPT TRIGGERED
[master (root-commit) c8678e0] first commit
1 file changed, 1 insertion(+)
create mode 100644 foo.txt

这就是你的第一个正常运行的 Git 钩子。

著名的 push-to-web 钩子

Git 钩子的一种流行用途是自动将更改推送到实时生产 Web 服务器目录。这是摆脱 FTP、保留对生产环境中内容的完整版本控制以及集成和自动化内容发布的好方法。

如果做得正确，它会非常出色地工作，并且在某种程度上，完全是 Web 发布应该一直以来的方式。它就是那么好。我不知道最初是谁想出了这个主意，但我第一次听说它是在我的 Emacs 和 Git 导师 Bill von Hagen 在 IBM 那里。他的文章仍然是对该过程的权威介绍：Git 改变了分布式 Web 开发的游戏规则。

Git 变量

每个 Git 钩子都获得一组与触发它的 Git 操作相关的不同变量。你可能需要也可能不需要使用这些变量；这取决于你要编写什么。如果你只想要一封通用电子邮件，提醒你有人推送了某些内容，那么你不需要具体信息，甚至可能不需要编写脚本，因为现有的示例可能对你有效。如果你想在电子邮件中查看提交消息和提交作者，那么你的脚本就会变得更加苛刻。

Git 钩子不是由用户直接运行的，因此弄清楚如何收集重要信息可能会令人困惑。实际上，Git 钩子脚本就像任何其他脚本一样，以 BASH、Python、C++ 和任何其他脚本相同的方式从 stdin 接受参数。不同之处在于，我们没有自己提供输入，因此要使用它，你需要知道期望什么。

在编写 Git 钩子之前，请查看 Git 在你的项目的 .git/hooks 目录中提供的示例。例如，pre-push.sample 文件在注释部分中说明

# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
# If pushing without using a named remote those arguments will be equal.
#
# Information about commit is supplied as lines
# to the standard input in this form:
# <local ref> <local sha1> <remote ref> <remote sha1>

并非所有示例都那么清楚，并且关于哪个钩子获得哪个变量的文档仍然有点稀疏（除非你想阅读 Git 的源代码），但如果对此有疑问，你可以从 其他用户的尝试 在线学习很多东西，或者只是编写一个基本脚本并回显 $1、$2、$3 等等。

分支检测示例

我发现生产实例中的一个常见要求是钩子，该钩子根据受影响的分支触发特定事件。以下是如何处理此类任务的示例。

首先，Git 钩子本身不受版本控制。也就是说，Git 不跟踪它自己的钩子，因为 Git 钩子是 Git 的一部分，而不是你的仓库的一部分。因此，监视提交和推送的 Git 钩子最好位于你的 Git 服务器上的裸仓库中，而不是作为你的本地仓库的一部分。

让我们编写一个在 post-receive 时运行的钩子（即，在收到提交后）。第一步是识别分支名称

#!/bin/tcsh

foreach arg ( $< )
  set argv = ( $arg )
  set refname = $1
end

此 for 循环读取第一个参数 ($1)，然后再次循环以使用第二个参数 ($2) 的值覆盖它，然后再使用第三个参数 ($3) 的值覆盖它。在 Bash 中有更好的方法来做到这一点：使用 read 命令并将值放入数组中。但是，由于这是 tcsh 并且变量顺序是可预测的，因此可以安全地破解它。

当我们拥有正在提交的内容的 refname 时，我们可以使用 Git 来发现分支的人类可读名称

set branch = `git rev-parse --symbolic --abbrev-ref $refname`
echo $branch #DEBUG

然后将分支名称与我们要基于操作的关键字进行比较

if ( "$branch" == "master" ) then
  echo "Branch detected: master"
  git \
    --work-tree=/path/to/where/you/want/to/copy/stuff/to \
    checkout -f $branch || echo "master fail"
else if ( "$branch" == "dev" ) then
  echo "Branch detected: dev"
  Git \
    --work-tree=/path/to/where/you/want/to/copy/stuff/to \
    checkout -f $branch || echo "dev fail"
  else
    echo "Your push was successful."
    echo "Private branch detected. No action triggered."
endif

使脚本可执行

$ chmod +x ~/jupiter/.git/hooks/post-receive

现在，当用户提交到服务器的 master 分支时，代码将复制到生产目录中，提交到 dev 分支的代码将复制到其他位置，而任何其他分支都不会触发任何操作。

创建一个 pre-commit 脚本也很简单，例如，检查是否有人试图推送到他们不应该推送的分支，或者解析提交消息以查找 approval 字符串等等。

Git 钩子可能会变得复杂，并且由于通过 Git 施加的抽象级别而可能令人困惑，但它们是一个强大的系统，可让你在 Git 基础设施中设计各种操作。它们值得涉足，即使只是为了熟悉该过程，如果你是认真的 Git 用户或全职 Git 管理员，则值得掌握。

在本系列的下一篇也是最后一篇文章中，我们将学习如何使用 Git 管理非文本二进制大对象，例如音频和图形文件。