The Protocols

Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. Here we’ll discuss what they are and in what basic circumstances you would want (or not want) to use them. git 可以主要使用四种协议传输数据， 本地 ssh ，git ，http。 在这里，我们将讨论它们是什么以及在什么样的基本情况，你想（或不想）使用他们

It’s important to note that with the exception of the HTTP protocols, all of these require Git to be installed and working on the server. 值得注意的是 除了http 协议外 其他的协议是确保git 顺利安装和工作所必须的。

Local Protocol

最基本的是本地的协议，在远程存储库是在另一个磁盘上的目录。这是经常使用的，如果你的团队中的每个人都可以访问的共享文件系统，如NFS安装，或在不太可能的情况下，每个人都登录到同一台计算机。后者是不理想的，因为所有的代码仓库实例都储存在同一台计算机，使一个灾难性损失的可能性。

If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. For example, to clone
a local repository, you can run something like this:

如果你有一个共享挂载的文件系统，那么你可以克隆，推动，和拉从一个本地的基于文件的存储库。为了这样或添加到现有项目中远程克隆一个仓库，使用到资源库中的URL路径。例如，如果要克隆一个本地仓库，你可以运行像这样：

$ git clone /opt/git/project.git

Or you can do this:

$ git clone file:///opt/git/project.git

Git operates slightly differently if you explicitly specify file:// at
the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specifyfile://,
Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify thefile:// prefix
is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because
doing so is almost always faster.

To add a local repository to an existing Git project, you can run something like this:

Git的运作方式略有不同，如果你明确地指定文件://开头的URL。如果你只给出路径，Git会尝试使用硬链接或者直接复制它需要的文件。如果您specifyfile:/ /，Git会调用的过程，它通常用来传输数据，通常是少了很多有效的方法，将数据传输网络。到中指定thefile://前缀的主要原因是，如果你想要一个干净的副本无关引用或对象库 - 一般从其他版本控制系统或类似的东西（见第9章的维护任务）后，进口。这里，我们将使用正常的路径，因为这样做总是会更快。

要添加一个本地仓库到现有的Git项目，你可以运行像这样：

$ git remote add local_proj /opt/git/project.git

Then, you can push to and pull from that remote as though you were doing so over a network.

然后，你就可以推和拉，远程好像你这样通过网络。

The Pros

The pros of file-based repositories are that they’re simple and they use existing file permissions and network access. If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. You stick the bare repository
copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. We’ll discuss how to export a bare repository copy for this purpose in the next section, “Getting Git on a Server.”

优点
基于文件的存储库的优点是，他们是简单的，他们使用现有的文件权限和网络访问的。如果你已经有你的整个团队有一个共享文件系统访问，建立一个资料库是很容易的。你坚持裸仓库的副本的地方大家共享访问并设置读/写权限，因为你会为任何其他的共享目录。我们将讨论如何导出一个裸仓库的副本为此目的在下一节中，“获得一个服务器上的Git。”

This is also a nice option for quickly grabbing work from someone else’s working repository. If you and a co-worker are working on the same project and they want you to check something out, running a command like git
pull /home/john/project is often easier than them pushing to a remote server and you pulling down.

这也是一个不错的选择，迅速抓工作，从别人的工作的仓库。如果你和你的同事都工作在同一个项目，他们希望你检查的东西，运行一个命令git pull /home/john/project往往更容易比他们推l拉到一个远程服务器

The Cons

The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. If you want to push from your laptop when you’re at home, you have to mount the remote disk, which can be difficult
and slow compared to network-based access.

这种方法的缺点是，一般比较难以建立，并达到比基本的网络访问从多个位置的共享访问。如果你想推，当你从你的笔记本电脑在家里，您必须安装远程磁盘相比，基于网络的访问，这可能是困难和缓慢的。

It’s also important to mention that this isn’t necessarily the fastest option if you’re using a shared mount of some kind. A local repository is fast only if you have fast access to the data. A repository on NFS is often slower than the repository over SSH
on the same server, allowing Git to run off local disks on each system.

值得一提的是，​​这并不一定是最快的选项，如果您使用的是共享安装的某种。本地仓库是快速的，如果你能快速地访问数据的。 NFS上的存储库往往是慢于同一台服务器上的存储库通过SSH，允许Git访问本地磁盘上的每个系统上。

The SSH Protocol

Probably the most common transport protocol for Git is SSH. This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do. SSH is also the only network-based protocol that you can easily read from and write to. The
other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands. SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s
generally easy to set up and use.

对于Git可能是最常见的传输协议是SSH。这是因为在大多数地方已经设置SSH访问服务器 - 如果它不是，它很容易做到。 SSH也是唯一的基于网络的协议，你可以很容易地读取和写入。另外两个网络协议（HTTP和Git）通常是读的，所以即使你有洗过群众，你还是需要SSH为自己的写命令。 SSH同时也是一个经过身份验证的网络协议，因为它是无处不在的，它通常是很容易设置和使用。

To clone a Git repository over SSH, you can specify ssh:// URL like this:

SSH克隆一个Git仓库，你可以指定ssh :/ /的URL是这样的：

$ git clone ssh://user@server:project.git

Or you can not specify a protocol — Git assumes SSH if you aren’t explicit:

或者你也可以指定一个协议 - Git的假设SSH，如果你不明确：

$ git clone user@server:project.git

You can also not specify a user, and Git assumes the user you’re currently logged in as.

也可以不指定用户，和Git假设你作为当前登录的用户。

The Pros

The pros of using SSH are many. First, you basically have to use it if you want authenticated write access to your repository over a network. Second, SSH is relatively easy to set up — SSH daemons are commonplace, many network admins have experience with them,
and many OS distributions are set up with them or have tools to manage them. Next, access over SSH is secure — all data transfer is encrypted and authenticated. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible
before transferring it.

使用SSH的优点是很多的。首先，你基本上要使用它，如果你想验证写访问版本库在网络上。其次，SSH是比较容易的设置 - SSH守护进程是家常便饭，很多网络管理员与他们的经验，很多操作系统都与他们有工具来管理它们。其次，通过SSH进行访问是安全的 - 所有的数据传输加密和认证。最后，像Git和本地协议，SSH是有效的，使数据尽可能紧凑传输之前。

The Cons

The negative aspect of SSH is that you can’t serve anonymous access of your repository over it. People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn’t make SSH access conducive to open source projects. If
you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. If you want to allow anonymous read-only access to your projects, you’ll have to set up SSH for you to push over but something else for others to pull over.

SSH的消极方面是，你不能给你的资料库的匿名访问。人们必须通过SSH访问你的机器来访问它，即使是在一个只读的能力，这不会使SSH访问，有利于开源项目。如果您使用的是只在您的企业网络中，SSH可能是你需要处理的协议。如果你想允许匿名只读访问到你的项目，你就必须设置SSH为你推过来，但别的东西给别人拉过来。

The Git Protocol

Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the
Git protocol, you must create the git-export-daemon-ok file
— the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable
push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.

接下来是Git协议。这是一个特殊的守护进程，使用Git包装;它会监听一个专门的端口（9418）的SSH协议提供的服务类似，但绝对没有认证。为了服务的存储库在Git协议，你必须创建git出口的守护确定的文件 - 守护进程将不会为一个存储库中没有该文件中 - 但除此之外，不存在安全。无论是Git仓库，供大家克隆或事实并非如此。这意味着，一般不存在推动通过此协议。您可以启用推送的访问权，但由于缺乏认证，如果你打开了推送权限，任何人在互联网上找到你的项目的URL可能会推到项目中。我只想说，这是傻X才干的。

The Pros

The Git protocol is the fastest transfer protocol available. If you’re serving a lot of traffic for a public project or serving a very large project that doesn’t require user authentication for read access, it’s likely that you’ll want to set up a Git daemon
to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead.

Git协议是最快的传输协议。如果你的公共项目，服务了大量的流量，或一个非常大的项目，不需要用户进行读访问的身份验证服务，它可能是你要成立一个Git守护进程，以满足您的项目。它使用了相同的数据传输机制作为SSH协议，但未经加密和认证的开销。

The Cons

The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone
else use git:// for
read-only access. It’s also probably the most difficult protocol to set up. It must run its own daemon, which is custom — we’ll look at setting one up in the “Gitosis” section of this chapter — it requires xinetdconfiguration
or the like, which isn’t always a walk in the park. It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked.

Git协议的不足之处是缺乏验证。 Git协议是唯一的访问到您的项目，这是不可取的。一般情况下，你会配对有一些开发商推（写）访问的SSH访问，并有其他人使用git:/ /只读访问权限。这也可能是最困难的协议成立。它必须运行其自己的守护进程，这是自定义的 - 我们将在本章中的“Gitosis的”部分设置一个 - ，它需要xinetdconfiguration或之类的，这并不一定是在公园里散步。这还需要防火墙访问9418端口，这是不是一个标准的企业防火墙总是允许的端口。大企业防火墙后面，这个不起眼的端口通常被屏蔽。

The HTTP/S Protocol

Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the simplicity of setting it up. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific post-update hook,
and you’re done (See Chapter 7 for details on Git hooks). At that point, anyone who can access the web server under which you put the repository can also clone your repository. To allow read access to your repository over HTTP, do something like this:

最后，我们的HTTP协议。 HTTP或HTTPS协议的美妙之处是它的简单。基本上，所有你所要做的就是把裸露的Git仓库，您的HTTP文档根目录下，并设置一个具体的post-update挂钩，你就大功告成了（上的Git挂钩的详细信息，请参阅第7章）。在这一点上，任何人都可以访问Web服务器下，你把仓库还可以克隆你的资料库。为了让读通过HTTP访问版本库，做这样的事情：

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

That’s all. The post-update hook
that comes with Git by default runs the appropriate command (git
update-server-info) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like

这就是全部。默认情况下，Git附带的post-update挂钩执行相应的命令（GIT更新服务器信息）通过HTTP的获取和克隆正常工作。当你把这个仓库通过SSH运行此命令，然后，其他人可以通过如下克隆

$ git clone http://example.com/gitproject.git

In this particular case, we’re using the /var/www/htdocs path
that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. The Git data is served as basic static files (see Chapter 9 for details about exactly how it’s served).

在这种特定的情况下，我们使用的/ var/ WWW/ htdocs目录路径为Apache设置是很常见的，但你可以使用任何静态的Web服务器 - 只是把裸露的资源库中的路径。 Git的数据提供最基本的静态文件（它究竟是如何提供的详细信息，请参阅第9章）。

It’s possible to make Git push over HTTP as well, although that technique isn’t as widely used and requires you to set up complex WebDAV requirements. Because it’s rarely used, we won’t cover it in this book. If you’re interested in using the HTTP-push protocols,
you can read about preparing a repository for this purpose athttp://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt.
One nice thing about making Git push over HTTP is that you can use any WebDAV server, without specific Git features; so, you can use this functionality if your web-hosting provider supports WebDAV for writing updates to your web site.

让Git推动通过HTTP，这是可能的，但这种技术没有得到广泛应用，并要求你设置复杂的WebDAV要求。因为它很少使用，我们不会将它覆盖在这本书中。如果你有兴趣使用的推HTTP协议的，你可以阅读有关准备一个仓库用于此目的http://www.starcite.com/html/legal.html上:/ / www.kernel.org的/ pub /软件/ SCM / GIT/文档/ HOWTO/设置的git服务器，过http.txt。推送HTTP的好处之一是，你可以使用任何WebDAV服务器，没有具体的Git的功能，因此，您可以使用此功能，如果您的网络托管服务提供商支持WebDAV更新写入到你的网站。

The Pros

The upside of using the HTTP protocol is that it’s easy to set up. Running the handful of required commands gives you a simple way to give the world read access to your Git repository. It takes only a few minutes to do. The HTTP protocol also isn’t very resource
intensive on your server. Because it generally uses a static HTTP server to serve all the data, a normal Apache server can serve thousands of files per second on average — it’s difficult to overload even a small server.

You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH
public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS.

的使用HTTP协议的好处是，它是很容易设置的。运行一些必要的命令，给你一个简单的方法，让全世界读取到仓库的。只需要几分钟的事。 HTTP协议是非常耗费资源，在您的服务器上。因为它一般只使用一个静态的HTTP服务提供所有的数据，可以作为一个普通的Apache服务器平均每秒成千上万的文件 - 这是难以甚至一个小型的服务器过载。

您也可以成为你的资料库只读，HTTPS，这意味着您可以加密内容传输，或者你可以走得很远，使客户端使用特定签名的SSL证书。一般情况下，如果你将这些长度，它更容易使用SSH的公共密钥，但它可能是一个更好的解决方案，您的具体情况，使用签名的SSL证书或其它基于HTTP的身份验证方法的只读访问HTTPS。

Another nice thing is that HTTP is such a commonly used protocol that corporate firewalls are often set up to allow traffic through this port.

另一个好消息是，HTTP等常用协议，企业防火墙通常设置为允许通过此端口的流量。

The Cons

The downside of serving your repository over HTTP is that it’s relatively inefficient for the client. It generally takes a lot longer to clone or fetch from the repository, and you often have a lot more network overhead and transfer volume over HTTP than with
any of the other network protocols. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a dumbprotocol.
For more information about the differences in efficiency between the HTTP protocol and the other protocols, see Chapter 9.

HTTP服务的版本库的缺点是，它是相对低效的客户端。它通常需要很长时间来克隆或从存储库中获取，而且你经常有更大量的网络开销和HTTP传输的体积比任何其他网络协议。因为它不是只传送数据，您需要为智能 - 有没有动态的工作的一部分，在这些交易中的服务器 - HTTP协议，通常被称为为一个dumbprotocol。对于HTTP协议和其他协议效率之间的差异的更多信息，请参阅第9章。