document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

finish translation (#4399)

Browse Source 
* translating by maywanting

* finish translating

* translating start

* delete the file

* 终于补完了！
This commit is contained in:
may 2016-09-12 23:24:00 +08:00 committed by Ezio
parent 1f92fc905b
commit 1ece52b0a6
2 changed files with 222 additions and 225 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

225
sources/tech/20160809 How to build your own Git server.md
View File

@ -1,225 +0,0 @@
translating by maywanting
How to build your own Git server
====================
![](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/bus-big-data.png?itok=sOQHDuID)
Now we will learn how to build a Git server, and how to write custom Git hooks to trigger specific actions on certain events (such as notifications), and publishing your code to a website.
Up until now, the focus has been interacting with Git as a user. In this article I'll discuss the administration of Git, and the design of a flexible Git infrastructure. You might think it sounds like a euphemism for "advanced Git techniques" or "only read this if you're a super-nerd", but actually none of these tasks require advanced knowledge or any special training beyond an intermediate understanding of how Git works, and in some cases a little bit of knowledge about Linux.
### Shared Git server
Creating your own shared Git server is surprisingly simple, and in many cases well worth the trouble. Not only does it ensure that you always have access to your code, it also opens doors to stretching the reach of Git with extensions such as personal Git hooks, unlimited data storage, and continuous integration and deployment.
If you know how to use Git and SSH, then you already know how to create a Git server. The way Git is designed, the moment you create or clone a repository, you have already set up half the server. Then enable SSH access to the repository, and anyone with access can use your repo as the basis for a new clone.
However, that's a little ad hoc. With some planning a you can construct a well-designed Git server with about the same amount of effort, but with better scalability.
First things first: identify your users, both current and in the future. If you're the only user then no changes are necessary, but if you intend to invite contributors aboard, then you should allow for a dedicated shared system user for your developers.
Assuming that you have a server available (if not, that's not exactly a problem Git can help with, but CentOS on a Raspberry Pi 3 is a good start), then the first step is to enable SSH logins using only SSH key authorization. This is much stronger than password logins because it is immune to brute-force attacks, and disabling a user is as simple as deleting their key.
Once you have SSH key authorization enabled, create the gituser. This is a shared user for all of your authorized users:
```
$ su -c 'adduser gituser'
```
Then switch over to that user, and create an ~/.ssh framework with the appropriate permissions. This is important, because for your own protection SSH will default to failure if you set the permissions too liberally.
```
$ su - gituser
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys
```
The authorized_keys file holds the SSH public keys of all developers you give permission to work on your Git project. Your developers must create their own SSH key pairs and send you their public keys. Copy the public keys into the gituser's authorized_keys file. For instance, for a developer called Bob, run these commands:
```
$ cat ~/path/to/id_rsa.bob.pub >> \
/home/gituser/.ssh/authorized_keys
```
As long as developer Bob has the private key that matches the public key he sent you, Bob can access the server as gituser.
However, you don't really want to give your developers access to your server, even if only as gituser. You only want to give them access to the Git repository. For this very reason, Git provides a limited shell called, appropriately, git-shell. Run these commands as root to add git-shell to your system, and then make it the default shell for your gituser:
```
# grep git-shell /etc/shells || su -c \
"echo `which git-shell` >> /etc/shells"
# su -c 'usermod -s git-shell gituser'
```
Now the gituser can only use SSH to push and pull Git repositories, and cannot access a login shell. You should add yourself to the corresponding group for the gituser, which in our example server is also gituser.
For example:
```
# usermod -a -G gituser seth
```
The only step remaining is to make a Git repository. Since no one is going to interact with it directly on the server (that is, you're not going to SSH to the server and work directly in this repository), make it a bare repository. If you want to use the repo on the server to get work done, you'll clone it from where it lives and work on it in your home directory.
Strictly speaking, you don't have to make this a bare repository; it would work as a normal repo. However, a bare repository has no *working tree* (that is, no branch is ever in a `checkout` state). This is important because remote users are not permitted to push to an active branch (how would you like it if you were working in a `dev` branch and suddenly someone pushed changes into your workspace?). Since a bare repo can have no active branch, that won't ever be an issue.
You can place this repository anywhere you please, just as long as the users and groups you want to grant permission to access it can do so. You do NOT want to store the directory in a user's home directory, for instance, because the permissions there are pretty strict, but in a common shared location, such as /opt or /usr/local/share.
Create a bare repository as root:
```
# git init --bare /opt/jupiter.git
# chown -R gituser:gituser /opt/jupiter.git
# chmod -R 770 /opt/jupiter.git
```
Now any user who is either authenticated as gituser or is in the gituser group can read from and write to the jupiter.git repository. Try it out on a local machine:
```
$ git clone gituser@example.com:/opt/jupiter.git jupiter.clone
Cloning into 'jupiter.clone'...
Warning: you appear to have cloned an empty repository.
```
Remember: developers MUST have their public SSH key entered into the authorized_keys file of gituser, or if they have accounts on the server (as you would), then they must be members of the gituser group.
### Git hooks
One of the nice things about running your own Git server is that it makes Git hooks available. Git hosting services sometimes provide a hook-like interface, but they don't give you true Git hooks with access to the file system. A Git hook is a script that gets executed at some point during a Git process; a hook can be executed when a repository is about to receive a commit, or after it has accepted a commit, or before it receives a push, or after a push, and so on.
It is a simple system: any executable script placed in the .git/hooks directory, using a standard naming scheme, is executed at the designated time. When a script should be executed is determined by the name; a pre-push script is executed before a push, a post-receive script is executed after a commit has been received, and so on. It's more or less self-documenting.
Scripts can be written in any language; if you can execute a language's hello world script on your system, then you can use that language to script a Git hook. By default, Git ships with some samples but does not have any enabled.
Want to see one in action? It's easy to get started. First, create a Git repository if you don't already have one:
```
$ mkdir jupiter
$ cd jupiter
$ git init .
```
Then write a "hello world" Git hook. Since I use tcsh at work for legacy support, I'll stick with that as my scripting language, but feel free to use your preferred language (Bash, Python, Ruby, Perl, Rust, Swift, Go) instead:
```
$ 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
```
Now test it out:
```
$ 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
```
And there you have it: your first functioning Git hook.
### The famous push-to-web hook
A popular use of Git hooks is to automatically push changes to a live, in-production web server directory. It is a great way to ditch FTP, retain full version control of what is in production, and integrate and automate publication of content.
If done correctly, it works brilliantly and is, in a way, exactly how web publishing should have been done all along. It is that good. I don't know who came up with the idea initially, but the first I heard of it was from my Emacs- and Git- mentor, Bill von Hagen at IBM. His article remains the definitive introduction to the process: [Git changes the game of distributed Web development][1].
### Git variables
Each Git hook gets a different set of variables relevant to the Git action that triggered it. You may or may not need to use those variables; it depends on what you're writing. If all you want is a generic email alerting you that someone pushed something, then you don't need specifics, and probably don't even need to write the script as the existing samples may work for you. If you want to see the commit message and author of a commit in that email, then your script becomes more demanding.
Git hooks aren't run by the user directly, so figuring out how to gather important information can be confusing. In fact, a Git hook script is just like any other script, accepting arguments from stdin in the same way that BASH, Python, C++, and anything else does. The difference is, we aren't providing that input ourselves, so to use it you need to know what to expect.
Before writing a Git hook, look at the samples that Git provides in your project's .git/hooks directory. The pre-push.sample file, for instance, states in the comments section:
```
# $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>
```
Not all samples are that clear, and documentation on what hook gets what variable is still a little sparse (unless you want to read the source code of Git), but if in doubt, you can learn a lot from the [trials of other users][2] online, or just write a basic script and echo $1, $2, $3, and so on.
### Branch detection example
I have found that a common requirement in production instances is a hook that triggers specific events based on what branch is being affected. Here is an example of how to tackle such a task.
First of all, Git hooks are not, themselves, version controlled. That is, Git doesn't track its own hooks because a Git hook is part of Git, not a part of your repository. For that reason, a Git hook that oversees commits and pushes probably make most sense living in a bare repository on your Git server, rather than as a part of your local repositories.
Let's write a hook that runs upon post-receive (that is, after a commit has been received). The first step is to identify the branch name:
```
#!/bin/tcsh
foreach arg ( $< )
set argv = ( $arg )
set refname = $1
end
```
This for-loop reads in the first arg ($1) and then loops again to overwrite that with the value of the second ($2), and then again with the third ($3). There is a better way to do that in Bash: use the read command and put the values into an array. However, this being tcsh and the variable order being predictable, it's safe to hack through it.
When we have the refname of what is being commited, we can use Git to discover the human-readable name of the branch:
```
set branch = `git rev-parse --symbolic --abbrev-ref $refname`
echo $branch #DEBUG
```
And then compare the branch name to the keywords we want to base the action on:
```
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
```
Make the script executable:
```
$ chmod +x ~/jupiter/.git/hooks/post-receive
```
Now when a user commits to the server's master branch, the code is copied to an in-production directory, a commit to the dev branch get copied someplace else, and any other branch triggers no action.
It's just as simple to create a pre-commit script that, for instance, checks to see if someone is trying to push to a branch that they should not be pushing to, or to parse commit messages for approval strings, and so on.
Git hooks can get complex, and they can be confusing due to the level of abstraction that working through Git imposes, but they're a powerful system that allows you to design all manner of actions in your Git infrastructure. They're worth dabbling in, if only to become familiar with the process, and worth mastering if you're a serious Git user or full-time Git admin.
In our next and final article in this series, we will learn how to use Git to manage non-text binary blobs, such as audio and graphics files.
--------------------------------------------------------------------------------
via: https://opensource.com/life/16/8/how-construct-your-own-git-server-part-6
作者：[Seth Kenlon][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[1]: http://www.ibm.com/developerworks/library/wa-git/
[2]: https://www.analysisandsolutions.com/code/git-hooks-summary-cheat-sheet.htm

222
translated/tech/20160809 How to build your own Git server.md Normal file
View File

@ -0,0 +1,222 @@
如何搭建你自己的 Git 服务器
====================
![](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/bus-big-data.png?itok=sOQHDuID)
现在我们将要学习如何搭建 git 服务器，如何编写自定义的 Git 钩子来在特定的事件触发相应的动作（例如通知），或者是发布你的代码到一个站点。
直到现在，作为一个使用者注意力还是被 Git 影响。这篇文章中我将讨论 Git 的管理，并且设计一个灵活的 Git 框架。你可能会觉得这听起来是 “高阶 Git 技术” 或者 “只有狂热粉才能阅读”的一句委婉的说法，但是事实是这里面的每个任务都不需要很深的知识或者其他特殊的训练，就能立刻理解 Git 的工作原理，有可能需要一丁点关于 Linux 的知识
### 共享 Git 服务器
创建你自己的共享 Git 服务器意外地简单，而且遇到各方面的问题时都很值得。不仅仅是因为它保证你有权限查看自己的代码，它还对于利用扩展来维持 Git 的通信敞开了一扇大门，例如个人 Git 钩子，无限制的数据存储，和持续的整合与发布
如果你知道如何使用 Git 和 SSH，那么你已经知道怎么创建一个 Git 服务器了。Git 的设计方式，就是让你在创建或者 clone 一个仓库的时候，就完成了一半服务器的搭建。然后允许用 SSH 访问仓库，而且任何有权限访问的人都可以使用你的仓库，作为 clone 的新仓库的基础。
但是，这是一个小的自组织。按照一些计划你可以以同样的效果创建一些设计优良的 Git 服务器，同时有更好的拓展性。
首要之事：确认你的用户们，现在的用户以及之后的用户都要考虑。如果你是唯一的用户那么没有任何改动的必要。但是如果你试图邀请其他的代码贡献者，那么你应该允许一个专门的分享系统用户给你的开发者们。
假定你有一个可用的服务器（如果没有，这不成问题，Git 会帮忙解决，CentOS 的 Raspberry Pi 3 是个不错的开始），然后第一步就是只允许使用 SSH 密钥认证的 SSH 登录。
一旦你启用了 SSH 密钥认证，创建 gituser 用户。这是给你的所有确认的开发者们的公共用户。
```
$ su -c 'adduser gituser'
```
然后切换到刚创建的 gituser 用户，创建一个 `~/.ssh` 的框架，并设置好合适的权限。这很重要，如果权限设置得太开放会使自己受保护的 SSH 默认失败。
```
$ su - gituser
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys
```
`authorized_keys` 文件里包含所有你的开发者们的 SSH 公钥，你开放权限允许他们可以在你的 Git 项目上工作。他们必须创建他们自己的 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 来 push 或者 pull Git 仓库，并且无法使用任何一个可以登录的 shell。你应该把你自己添加到和 gituser 一样的组中，在我们的样例服务器中仍是这个组的名字仍是 gituser。
举个例子：
```
# usermod -a -G gituser seth
```
仅剩下的一步就是创建一个 Git 仓库。因为没有人能在服务器上与 Git 交互（也就是说，你之后不能 SSH 到服务器然后直接操作这个仓库），创一个最原始的仓库 。如果你想使用位于服务器上的仓库来完成工作，你可以从它的所在处 clone 下来然后直接在你的 home 目录下工作。
说白了，你不需要让它变成一个空的仓库，你需要像工作在一个正常的仓库一样。但是，一个空的仓库没有 *working tree* （也就是说，使用 `checkout` 并没有任何分支显示）。这很重要，因为远程使用者们并不被允许 push 一个有效的分支（如果你正在 `dev` 分支工作然后突然有人把一些变更 push 到你的工作分支，你会有怎么样的感受？）。因为一个空的仓库可以没有有效的分支，这不会成为一个问题。
你可以把这个仓库放到任何你想放的地方，只要你想要放开权限给用户和用户组，让他们可以在仓库下工作。千万不要保存目录到例如一个用户的 home 目录下，因为有严格的权限控制。保存到一个常规的共享地址，例如 `/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 过程的某些点运行；当一个仓库即将接收一个 commit，或者接受一个 commit 之后，或者即将接收一次 push，或者一次 push 之后等等
这是一个简单的系统：任何放在 `.git/hooks` 目录下的脚本，使用标准的命名体系，就可按设计好的时间运行。一个脚本是否应该被运行取决于它的名字； pre-push 脚本在 push 之前运行，post-received 脚本在 push 之后运行，post-receive 脚本在接受 commit 之后运行等等。
脚本可以用任何语言写；如果在你的系统上有可以执行的脚本语言，例如输出 ‘hello world’ ，那么你就用这个语言来写 Git 钩子脚本。Git 默认会给出一些例子，但是并不能用。
想要动手试一个？这很简单。如果你没有现成的 Git 仓库，首先创建一个 Git 仓库：
```
$ mkdir jupiter
$ cd jupiter
$ git init .
```
然后写一个功能为输出 “hello world” 的 Git 钩子。因为我使用 tsch 作为传统系统的长期支持 shell，所以我仍然用它作为我的脚本语言，你可以自由的使用自己喜欢的语言（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 钩子最流行的用法就是自动 push 更改的代码到一个正在使用中的网络服务器目录下。这是摆脱 FTP 的很好的方式，对于正在使用的产品保留完整的版本控制，自动整合发布的内容
如果操作正确，在一直以来的网站发布维护中 Git 会完成的很好，而且在某种程度上，很精准。Git 真的好棒。我不知道谁最初想到这个主意，但是我第一次听到它是从 Emacs 和 Git 方面的专家，IBM 的 Bill von Hagen。他的文章包含一系列明确的介绍：[Git 改变了分布式网页开发的游戏规则][1]。
### Git 变量
每一个 Git 钩子都有一系列不同的变量对应触发钩子的不同 Git 行为。你需不需要这些变量，主要取决于你写的程序。如果你需要一个当某人 push 代码时候的通用邮件通知，那么你就不需要特殊化，并且甚至也不需要编写额外的脚本，因为已经有现成的适合你的脚本。如果你想在邮件里查看 commit 信息和 commit 的作者，那么你的脚本就会变得相对棘手些。
Git 钩子并不是被用户直接执行，所以要弄清楚如何收集可能会误解的重要信息。事实上，Git 钩子脚本就像其他的脚本一样，像 BASH, Python, C++ 等等，从标准输入读取参数。不同的是，我们不会给它提供这个输入，所以，你在使用的时候，需要知道可能的输入参数。
在写 Git 钩子之前，看一下 Git 在你的项目目录下 `.git/hooks` 目录中提供的一些例子。举个例子，在这个 `pre-push.sample` 文件里，注释部分说明了如下内容：
```
# $1 -- 即将 push 的远方仓库的名字
# $2 -- 即将 push 的远方仓库的 URL
# 如果 push 的时候，并没有一个命名的远方仓库，那么这两个参数将会一样。
#
# 对于这个表单的标准输入,
# 参数通过行的形式输入
# <local ref> <local sha1> <remote ref> <remote sha1>
```
并不是所有的例子都是这么清晰，而且关于钩子获取变量的文档依旧缺乏（除非你去读 Git 的源码）。但是，如果你有疑问，你可以从[其他用户的尝试中][2]学习，或者你只是写一些基本的脚本，比如 `echo $1, $2, $3` 等等。
### 分支检测示例
我发现，对于生产环境来说有一个共同的需求，就是需要一个只有在特定分支被修改之后，才会触发事件的钩子。以下就是如何跟踪分支的示例。
首先，Git 钩子本身是不受版本控制的。 Git 并不会跟踪他自己的钩子，因为对于钩子来说，他是 Git 的一部分，而不是你仓库的一部分。所以，Git 钩子可以监控你的 Git 服务器上的 Git 仓库的 commit 记录和 push 记录，而不是你本地仓库的一部分。
我们来写一个 post-receive（也就是说，在 commit 被接受之后触发）钩子。第一步就是需要确定分支名：
```
#!/bin/tcsh
foreach arg ( $< )
set argv = ( $arg )
set refname = $1
end
```
这个 for 循环用来读入第一个参数 `arg($1)` 然后循环用第二个参数 `($2)` 去重写，然后用第三个参数 `($3)` 。在 Bash 中有一个更好的方法，使用 read 命令，并且把值放入数组里。但是，这里是 tcsh，并且变量的顺序可以预测的，所以，这个方法也是可行的。
当我们有了 commit 记录的 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 分支 commit 代码，这个代码就会被复制到一个生产环境的目录，dev 分支的一个 commit 记录也会被复制到其他地方，其他分支将不会触发这些操作。
同时，创造一个 pre-commit 脚本也很简单。比如，判断一个用户是否在他们不该 push 的分支上 push 代码，或者对 commit 信息进行解析等等。
Git 钩子也可以变得复杂，而且他们因为 Git 的工作流的抽象层次不同而变得难以理解，但是他们确实是一个强大的系统，让你能够在你的 Git 基础设施上针对所有的行为进行对应的操作。如果你是一个 Git 重度用户，或者一个全职 Git 管理员，那么 Git 钩子是值得学习的。
在我们这个系列之后和最后的文章，我们将会学习如何使用 Git 来管理非文本的二进制数据，比如音频和图片。
--------------------------------------------------------------------------------
via: https://opensource.com/life/16/8/how-construct-your-own-git-server-part-6
作者：[Seth Kenlon][a]
译者：[maywanting](https://github.com/maywanting)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[1]: http://www.ibm.com/developerworks/library/wa-git/
[2]: https://www.analysisandsolutions.com/code/git-hooks-summary-cheat-sheet.htm