git32位服务器构建_如何构建自己的Git服务器

git32位服务器构建

读：

• 第1部分：什么是Git？
• 第2部分：Git入门
• 第3部分：创建第一个Git存储库
• 第4部分：如何在Git中还原旧文件版本
• 第5部分：3个用于Git的图形工具
• 第6部分：如何构建自己的Git服务器
• 第7部分：如何使用Git管理二进制Blob

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

到目前为止，焦点一直是作为用户与Git进行交互。 在本文中，我将讨论Git的管理以及灵活的Git基础结构的设计。 您可能会认为这听起来像是对“高级Git技术”的委婉说法，或者“只有在您是超级书呆子的情况下才阅读此书”，但是实际上，除了对Git的工作方式有中等了解之外，所有这些任务都不需要高级知识或任何特殊培训，在某些情况下，还会对Linux有一点了解。

共享Git服务器

创建您自己的共享Git服务器非常简单，在很多情况下，这是值得的。 它不仅确保您始终可以访问代码，而且还通过扩展功能（如个人Git钩子，无限的数据存储以及持续的集成和部署）扩展了Git的范围。

开源git服务器， 如果您知道如何使用Git和SSH，那么您已经知道如何创建Git服务器。 Git的设计方式，一旦创建或克隆存储库，就已经设置了一半的服务器。 然后启用对存储库的SSH访问，任何具有访问权限的人都可以使用您的存储库作为新克隆的基础。

但是，这是临时的 。 通过一些计划，您可以以大约相同的努力来构建设计良好的Git服务器，但具有更好的可伸缩性。

首先，要确定当前和将来的用户。 如果您是唯一的用户，则不需要进行任何更改，但是如果您打算邀请贡献者加入，则应该为开发人员允许一个专用的共享系统用户。

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

启用S​​SH密钥授权后，创建gituser 。 这是您所有授权用户的共享用户：

 $  su -c 'adduser gituser' 

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

$ su - gituser

$ mkdir .ssh && chmod 700 .ssh

$ touch .ssh / authorized_keys

$ chmod 600 .ssh / authorized_keys

服务器创建git库、 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提供了一个受限制的外壳，适当地称为git-shell 。 以超级用户身份运行以下命令以将git-shell添加到您的系统，然后将其设为gituser的默认外壳：

 # 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到服务器并直接在此存储库中工作），因此使其成为一个裸露的存储库。 如果要使用服务器上的存储库来完成工作，则可以从其存放位置克隆它并在主目录中对其进行处理。

git没有权限， 严格来说，您不必将其变成裸露的存储库。 它可以作为正常的回购协议。 但是，裸仓库没有*工作树*（也就是说，没有分支处于`checkout'状态）。 这很重要，因为不允许远程用户推送到活动分支（如果您在`dev`分支中工作并且突然有人将更改推送到工作区中，您会怎么想？）。 由于裸仓库不能有活动分支，所以永远不会成为问题。

只要您要授予访问权限的用户和组可以这样做，就可以将此存储库放置在任意位置。 例如，您不希望将目录存储在用户的主目录中，因为那里的权限非常严格，但是存储在公共共享位置，例如/ opt或/ usr / local / share。

以根用户身份创建一个裸仓库：

 # 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 / hooks目录中放置的任何可执行脚本都在指定的时间执行。 何时执行脚本由名称决定； 在pre-push之前执行pre-push脚本，在post-receive到提交之后执行后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钩子。

著名的推网钩

构建云服务器？ Git挂钩的一种流行用法是将更改自动推送到实时的生产中Web服务器目录中。 这是放弃FTP，保留对生产内容的完整版本控制以及集成和自动发布内容的好方法。

如果做得正确，它将发挥出色的作用，并且在某种程度上完全是应该一直进行Web发布的方式。 就是那样 我最初不知道是谁提出这个主意的，但是我第一次听说这个主意的是我的Emacs和Gitmentor的IBM的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服务器上的裸存储库中，而不是作为本地存储库的一部分。

让我们编写一个在接收后（即在接收到提交之后）运行的钩子。 第一步是确定分支名称：

 #!/bin/tcsh 


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

end

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

当我们有refname的被COMMITED什么，我们可以使用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分支的提交复制到其他位置，而其他任何分支都不会触发任何操作。

创建一个预提交脚本就很简单，例如，该脚本检查某人是否试图将其推入不应该推入的分支，或者分析提交消息以获取批准字符串，等等。

Git挂钩可能会变得很复杂，并且由于通过Git施加的抽象级别而变得混乱，但是它们是一个功能强大的系统，可让您设计Git基础架构中的所有操作方式。 如果只是熟悉此过程，那么值得一试；如果您是认真的Git用户或专职Git管理员，则值得掌握。

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

翻译自: https://opensource.com/life/16/8/how-construct-your-own-git-server-part-6

什么是服务器、git32位服务器构建