如何构建您自己的 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 发布应该一直以来的方式。它就是那么好。我不知道最初是谁提出了这个想法，但我第一次听说它是从我在 IBM 的 Emacs 和 Git 导师 Bill von Hagen 那里听说的。他的文章仍然是对该过程的权威介绍：《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 管理非文本二进制大对象，例如音频和图形文件。