4.1 Git on the Server - The Protocols
至此，你应该可以完成大部分日常工作，而这些工作都需要用到 Git。不过，要在 Git 上进行任何协作，你都需要一个远程 Git 仓库。虽然从技术上讲，你可以推送改动到个人仓库，也可以从个人仓库中拉取改动，但这样做并不可取，因为稍有不慎，你就很容易混淆他们的工作内容。此外，即使你的电脑处于离线状态，你也希望你的合作者能够访问版本库--拥有一个更可靠的共同版本库通常会很有用。因此，与他人协作的首选方法是建立一个双方都能访问的中间版本库，并从该版本库中推送和提取。
At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git. However, in order to do any collaboration in Git, you’ll need to have a remote Git repository. Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they’re working on if you’re not careful. Furthermore, you want your collaborators to be able to access the repository even if your computer is offline — having a more reliable common repository is often useful. Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that.
运行 Git 服务器相当简单。首先，选择服务器要支持的协议。本章第一节将介绍可用的协议及其优缺点。接下来，我们将介绍一些使用这些协议的典型设置，以及如何使用它们运行服务器。最后，如果你不介意将代码托管在别人的服务器上，又不想经历架设和维护自己服务器的麻烦，我们将介绍几种托管方案。
Running a Git server is fairly straightforward. First, you choose which protocols you want your server to support. The first section of this chapter will cover the available protocols and the pros and cons of each. The next sections will explain some typical setups using those protocols and how to get your server running with them. Last, we’ll go over a few hosted options, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server.
如果你对运行自己的服务器不感兴趣，可以跳到本章最后一节，查看设置托管账户的一些选项，然后进入下一章，我们将讨论在分布式源码控制环境中工作的各种来龙去脉。
If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment.
远程仓库通常是一个裸仓库 --- 一个没有工作目录的 Git 仓库。因为该仓库只用作协作点，所以没有理由在磁盘上签出快照；它只是 Git 数据而已。最简单地说，裸仓库就是项目 .git 目录的内容，没有其他任何东西。
A remote repository is generally a bare repository — a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data. In the simplest terms, a bare repository is the contents of your project’s .git directory and nothing else.
The Protocols
Git 可以使用四种不同的协议传输数据： 本地、HTTP、安全外壳（SSH）和 Git。下面我们将讨论它们分别是什么，以及在什么基本情况下需要（或不需要）使用它们。
Git can use four distinct protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. Here we’ll discuss what they are and in what basic circumstances you would want (or not want) to use them.
Local Protocol
最基本的是本地协议，即远程存储库位于同一主机上的另一个目录中。如果团队中的每个人都能访问共享文件系统（如 NFS 挂载），或者每个人都登录到同一台计算机，这种情况下通常会使用本地协议。后者并不理想，因为你的所有代码库实例都位于同一台计算机上，这就更有可能造成灾难性的损失。( https://en.wikipedia.org/wiki/Network_File_System )
如果你有一个共享挂载的文件系统，那么你就可以从基于本地文件的版本库中克隆、推送或提取代码。要克隆这样的版本库，或将其作为远程版本库添加到现有项目中，请使用版本库的路径作为 URL。例如，要克隆一个本地版本库，可以运行下面的命令：
The most basic is the Local protocol, in which the remote repository is in another directory on the same host. This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. The latter wouldn’t be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely.
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:
$ git clone /srv/git/project.git
Or you can do this:
$ git clone file:///srv/git/project.git
如果在 URL 开头明确指定 file://，Git 的操作会略有不同。如果只指定路径，Git 会尝试使用硬链接或直接复制所需的文件。如果指定了 file://，Git 就会启动通常用于通过网络传输数据的进程，这通常会大大降低效率。指定 file:// 前缀的主要原因是，你需要一个干净的版本库副本，不包含无关的引用或对象--通常是在从其他 VCS 或类似系统导入之后。我们在此使用正常路径，因为这样做几乎总是更快。
要在现有的 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 specify file://, Git fires up the processes that it normally uses to transfer data over a network, which is generally much less efficient. The main reason to specify the file:// prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another VCS or something similar. 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 remote add local_proj /srv/git/project.git
然后，你就可以通过新的名称 local_proj向该远程仓库推送或提取数据，好像通过网络操作一样。
Then, you can push to and pull from that remote via your new remote name local_proj as though you were doing so over a network.
The Pros 优点
基于文件的存储库的优点是简单，而且可以使用现有的文件权限和网络访问。如果你已经有一个共享文件系统，整个团队都可以访问，那么建立一个版本库就非常容易了。你只需将裸仓库副本放在每个人都能共享访问的地方，然后像其他共享目录一样设置读/写权限即可。我们将在《 在服务器上获取 Git》一文中讨论如何为此目的导出裸仓库副本。 ( Git - Getting Git on a Server)
这也是一个不错的选择，可以快速从别人的工作仓库中抓取工作内容。如果你和同事在同一个项目上工作，而他们想让你检查某些东西，运行类似 git pull /home/john/project 这样的命令往往比他们推送到远程服务器，然后你再从中获取要容易得多。
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 Getting Git on a Server.
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 subsequently fetching from it.
The Cons 缺点
这种方法的缺点是，与基本的网络访问相比，共享访问通常更难设置，也更难从多个地点进行访问。如果你在家时想从笔记本电脑推送，就必须加载远程磁盘，这可能比基于网络的访问困难和缓慢。
值得一提的是，如果你使用的是某种共享挂载，这并不一定是最快的选择。只有当你能快速访问数据时，本地存储库才是最快的。NFS 上的版本库通常比同一服务器上通过 SSH 运行的版本库要慢，因为SSH访问时，Git 可以在每个系统的本地磁盘上运行。
最后，该协议无法保护版本库免受意外破坏。每个用户都有访问 "远程 "目录的完整 shell 权限，没有什么能阻止他们更改或删除 Git 内部文件并破坏版本库。
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 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.
Finally, this protocol does not protect the repository against accidental damage. Every user has full shell access to the “remote” directory, and there is nothing preventing them from changing or removing internal Git files and corrupting the repository.
The HTTP Protocols
Git 可以通过 HTTP 以两种不同的模式进行通信。在 Git 1.6.6 之前，只有一种方式可以做到这一点，那就是非常简单的只读模式。在 1.6.6 版本中，Git 引入了一种更智能的新协议，它能以类似 SSH 的方式智能协商数据传输。最近几年，这种新的 HTTP 协议变得非常流行，因为它对用户来说更简单，通信方式也更智能。新版本通常被称为智能 HTTP 协议，而旧版本则被称为傻瓜 HTTP。我们将首先介绍较新的智能 HTTP 协议。
Git can communicate over HTTP using two different modes. Prior to Git 1.6.6, there was only one way it could do this which was very simple and generally read-only. In version 1.6.6, a new, smarter protocol was introduced that involved Git being able to intelligently negotiate data transfer in a manner similar to how it does over SSH. In the last few years, this new HTTP protocol has become very popular since it’s simpler for the user and smarter about how it communicates. The newer version is often referred to as the Smart HTTP protocol and the older way as Dumb HTTP. We’ll cover the newer Smart HTTP protocol first.
Smart HTTP 智能HTTP
智能 HTTP 的运行方式与 SSH 或 Git 协议非常相似，但它通过标准 HTTPS 端口运行，并可使用各种 HTTP 身份验证机制，这意味着它对用户来说往往比 SSH 更简单，因为你可以使用用户名/密码等身份验证方式，而不必设置 SSH 密钥。
它可能已成为目前最流行的 Git 使用方式，因为它既可以像 git:// 协议那样匿名提供服务，也可以像 SSH 协议那样通过身份验证和加密推送。你不必再为这些事情设置不同的 URL，现在只需使用一个 URL 即可实现这两种功能。如果你尝试推送，而版本库要求身份验证（通常应该如此），服务器会提示你输入用户名和密码。读取访问也是如此。
事实上，对于像 GitHub 这样的服务，你用来在线查看版本库的 URL（例如 GitHub - schacon/simplegit: example repo used for testing and such）与你用来克隆和推送（如果你有访问权限）的 URL 是一样的。
Smart HTTP operates very similarly to the SSH or Git protocols but runs over standard HTTPS ports and can use various HTTP authentication mechanisms, meaning it’s often easier on the user than something like SSH, since you can use things like username/password authentication rather than having to set up SSH keys.
It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the git:// protocol, and can also be pushed over with authentication and encryption like the SSH protocol. Instead of having to set up different URLs for these things, you can now use a single URL for both. If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password. The same goes for read access.
In fact, for services like GitHub, the URL you use to view the repository online (for example, https://github.com/schacon/simplegit) is the same URL you can use to clone and, if you have access, push over.
Dumb HTTP 傻瓜HTTP
如果服务器没有回应 Git HTTP 智能服务，Git 客户端就会尝试使用更简单的 Dumb HTTP 协议。Dumb 协议希望裸 Git 仓库能像普通文件一样从网络服务器提供服务。Dumb HTTP 的优点在于设置简单。基本上，你只需在 HTTP 文档根目录下放置一个裸 Git 仓库，并设置一个特定的post-update钩子，就大功告成了（参见 Git 钩子）。这样，任何能访问你所放置仓库的网络服务器的人都能克隆你的仓库。要允许通过 HTTP 对版本库进行读取访问，可以这样做：
If the server does not respond with a Git HTTP smart service, the Git client will try to fall back to the simpler Dumb HTTP protocol. The Dumb protocol expects the bare Git repository to be served like normal files from the web server. The beauty of Dumb HTTP is the simplicity of setting it up. Basically, all you have to do is put a bare Git repository under your HTTP document root and set up a specific post-update hook, and you’re done (see 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:
$ 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
就是这样。Git 默认自带的post-update钩子会运行相应的命令（git update-server-info），使 HTTP 抓取和克隆正常工作。当你推送到这个仓库时（也许是通过 SSH），这个命令就会运行；然后，其他人就可以通过类似以下的方式克隆了：
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 perhaps); then, other people can clone via something like:
$ git clone https://example.com/gitproject.git
在本例中，我们使用的是 Apache 设置中常见的 /var/www/htdocs 路径，但你也可以使用任何静态网站服务器，只需将裸仓库放在其路径中即可。Git 数据以基本的静态文件形式提供（具体提供方式详见 Git Internals 章节）。
一般来说，你可以选择运行一个可读写的智能 HTTP 服务器，或者直接以只读方式访问文件的傻瓜HTTP服务器。混合运行这两种服务的情况很少见。
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 the Git Internals chapter for details about exactly how it’s served).
Generally you would either choose to run a read/write Smart HTTP server or simply have the files accessible as read-only in the Dumb manner. It’s rare to run a mix of the two services.
The Pros 优点
我们将集中讨论智能版 HTTP 协议的优点。
所有类型的访问都使用一个 URL，服务器只在需要验证时才提示，这种简单的操作方式让最终用户非常容易上手。与 SSH 相比，使用用户名和密码进行身份验证也是一大优势，因为用户不必在本地生成 SSH 密钥，也不必在与服务器交互前将公钥上传到服务器。对于不太复杂的用户或使用 SSH 不太常见的系统的用户来说，这是可用性方面的一大优势。这也是一个非常快速高效的协议，与 SSH 类似。
你还可以通过 HTTPS 以只读方式为存储库提供服务，这意味着你可以对内容传输进行加密；或者你还可以让客户端使用特定签名的 SSL 证书。
另一个好处是，HTTP 和 HTTPS 是非常常用的协议，企业防火墙通常会设置为允许流量通过它们的端口。
We’ll concentrate on the pros of the Smart version of the HTTP protocol.
The simplicity of having a single URL for all types of access and having the server prompt only when authentication is needed makes things very easy for the end user. Being able to authenticate with a username and password is also a big advantage over SSH, since users don’t have to generate SSH keys locally and upload their public key to the server before being able to interact with it. For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. It is also a very fast and efficient protocol, similar to the SSH one.
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.
Another nice thing is that HTTP and HTTPS are such commonly used protocols that corporate firewalls are often set up to allow traffic through their ports.
The Cons 缺点
与某些服务器上的 SSH 相比，HTTPS 上的 Git 设置可能更麻烦一些。除此之外，与智能 HTTP 相比，其他协议在提供 Git 内容方面几乎没有什么优势。
如果使用 HTTP 进行验证推送，提供凭据有时比通过 SSH 使用密钥更复杂。不过，你可以使用几种凭证缓存工具，包括 macOS 上的钥匙串访问和 Windows 上的凭证管理器，让这一切变得非常简单。阅读 " 凭证存储"，了解如何在系统上设置安全的 HTTP 密码缓存。( Git - Credential Storage)
Git over HTTPS can be a little more tricky to set up compared to SSH on some servers. Other than that, there is very little advantage that other protocols have over Smart HTTP for serving Git content.
If you’re using HTTP for authenticated pushing, providing your credentials is sometimes more complicated than using keys over SSH. There are, however, several credential caching tools you can use, including Keychain access on macOS and Credential Manager on Windows, to make this pretty painless. Read Credential Storage to see how to set up secure HTTP password caching on your system.
The SSH Protocol
自托管时，Git 常用的传输协议是 SSH。这是因为大多数地方已经设置了 SSH 访问服务器，即使没有，也很容易设置。SSH 也是一种经过验证的网络协议，而且因为它无处不在，所以通常很容易设置和使用。
要通过 SSH 克隆 Git 仓库，可以像下面这样指定一个 ssh:// URL：
A common transport protocol for Git when self-hosting is over 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 an authenticated network protocol and, because it’s ubiquitous, it’s generally easy to set up and use.
To clone a Git repository over SSH, you can specify an ssh:// URL like this:
$ git clone ssh://[user@]server/project.git
或者使用 SSH 协议中更短的类似 scp 的语法：
Or you can use the shorter scp-like syntax for the SSH protocol:
$ git clone [user@]server:project.git
在上述两种情况下，如果您不指定可选的用户名，Git 会使用你当前登录的用户。
In both cases above, if you don’t specify the optional username, Git assumes the user you’re currently logged in as.
The Pros 优点
使用 SSH 有很多好处。首先，SSH 的设置相对简单--SSH 守护进程很常见，许多网络管理员都有使用经验，而且许多操作系统发行版都有设置或管理它们的工具。其次，通过 SSH 进行访问是安全的--所有数据传输都经过加密和验证。最后，与 HTTPS、Git 和本地协议一样，SSH 也很高效，在传输数据前会尽可能压缩数据。
The pros of using SSH are many. First, 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 HTTPS, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it.
The Cons 缺点
SSH 的缺点是不支持匿名访问 Git 仓库。如果你使用 SSH，别人就必须有 SSH 访问你机器的权限，哪怕是只读权限，这使得 SSH 不利于开源项目，因为别人可能只是想克隆你的仓库来检查它。如果你只在公司网络内使用，SSH 可能是你唯一需要处理的协议。如果你想允许匿名只读访问你的项目，同时又想使用 SSH，那么你就必须自己把SSH设置成可推送，而让其他人从其他地方获取。
The negative aspect of SSH is that it doesn’t support anonymous access to your Git repository. If you’re using SSH, people must have SSH access to your machine, even in a read-only capacity, which doesn’t make SSH conducive to open source projects for which people might simply want to clone your repository to examine it. 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 and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch from.
The Git Protocol
最后是 Git 协议。这是 Git 附带的一个特殊守护进程；它通过一个专用端口（9418）监听，提供类似 SSH 协议的服务，但完全没有身份验证或加密。要通过 Git 协议管理一个仓库，你必须创建一个 git-daemon-export-ok 文件--没有这个文件，守护进程是不会管理仓库的，而且没有安全功能。Git 仓库要么可供所有人克隆，要么不能。这就意味着，一般情况下无法通过该协议进行推送。你可以启用推送访问，但由于缺乏身份验证，互联网上的任何人只要找到你项目的 URL，就可以推送到该项目。只能说这种情况很少见。
Finally, we have 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 or cryptography. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-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, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.
The Pros 优点
Git 协议通常是最快的网络传输协议。如果你正在为一个公共项目提供大量流量，或者正在为一个不需要用户身份验证就能读取访问的大型项目提供服务，那么你很可能会想要设置一个 Git 守护进程来为你的项目提供服务。它使用与 SSH 协议相同的数据传输机制，但不需要加密和身份验证。
The Git protocol is often the fastest network 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.
The Cons 缺点
由于缺乏 TLS 或其他加密技术，通过 git:// 克隆可能会导致任意代码执行漏洞，因此除非您知道自己在做什么，否则应避免使用。
-
如果运行 git clone git://example.com/project.git，控制路由器等设备的攻击者就可以修改刚刚克隆的 repo，在其中插入恶意代码。如果您编译/运行刚刚克隆的代码，就会执行恶意代码。出于同样的原因，应避免运行 git clone http://example.com/project.git。
-
运行 git clone https://example.com/project.git 不会有同样的问题（除非攻击者能提供 example.com 的 TLS 证书）。只有在接受了错误的 SSH 密钥指纹的情况下，运行 git clone git@example.com:project.git 才会出现这个问题。
它也没有身份验证，即任何人都可以克隆 repo（尽管这往往正是你想要的）。它可能也是最难设置的协议。它必须运行自己的守护进程，这就需要 xinetd 或 systemd 配置等，而这并不总是轻而易举的事。它还需要防火墙访问 9418 端口，而这并不是企业防火墙总是允许的标准端口。在大型企业的防火墙后面，这个不起眼的端口通常会被屏蔽。
Due to the lack of TLS or other cryptography, cloning over git:// might lead to an arbitrary code execution vulnerability, and should therefore be avoided unless you know what you are doing.
* If you run git clone git://example.com/project.git, an attacker who controls e.g your router can modify the repo you just cloned, inserting malicious code into it. If you then compile/run the code you just cloned, you will execute the malicious code. Running git clone http://example.com/project.git should be avoided for the same reason.
* Running git clone https://example.com/project.git does not suffer from the same problem (unless the attacker can provide a TLS certificate for example.com). Running git clone git@example.com:project.git only suffers from this problem if you accept a wrong SSH key fingerprint.
It also has no authentication, i.e. anyone can clone the repo (although this is often exactly what you want). It’s also probably the most difficult protocol to set up. It must run its own daemon, which requires xinetd or systemd configuration 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.
参考：
![[Cloud Networking] Layer <span style='color:red;'>Protocol</span> (continue)](https://img-blog.csdnimg.cn/img_convert/88dad7190e4bc17fd6e181dfb9ee9d04.webp?x-oss-process=image/format,png)
![[Electron]中IPC进程间通信](https://img-blog.csdnimg.cn/direct/5aadb7e202e7451fb49c0365467ecf04.png)
