00. 目录
文章目录
01. 概述
到目前为止已经有办法使用 Git 来完成日常工作。 然而，为了使用 Git 协作功能，你还需要有远程的 Git 仓库。 尽管在技术上可以从个人仓库进行推送（push）和拉取（pull）来修改内容，但不鼓励使用这种方法，因为一不留心就很容易弄混其他人的进度。 此外，你希望你的合作者们即使在你的电脑未联机时亦能存取仓库 — 拥有一个更可靠的公用仓库十分有用。 因此，与他人合作的最佳方法即是建立一个你与合作者们都有权利访问，且可从那里推送和拉取资料的共用仓库。
架设一台 Git 服务器并不难。 首先，选择你希望服务器使用的通讯协议。 在本章将介绍可用的协议以及各自优缺点。 下面一节将解释使用那些协议的典型设置及如何在你的服务器上运行。 最后，如果你不介意托管你的代码在其他人的服务器，且不想经历设置与维护自己服务器的麻烦，可以试试我们介绍的几个仓库托管服务。
一个远程仓库通常只是一个裸仓库（bare repository）——即一个没有当前工作目录的仓库。 因为该仓库仅仅作为合作媒介，不需要从磁盘检查快照；存放的只有 Git 的资料。 简单的说，裸仓库就是你工程目录内的 .git 子目录内容，不包含其他资料。
02. 协议
Git 可以使用四种不同的协议来传输资料：本地协议（Local），HTTP 协议，SSH（Secure Shell）协议及 Git 协议。 在此，我们将会讨论那些协议及哪些情形应该使用（或避免使用）他们。
2.1 本地协议
最基本的就是 本地协议（Local protocol） ，其中的远程版本库就是同一主机上的另一个目录。 这常见于团队每一个成员都对一个共享的文件系统（例如一个挂载的 NFS）拥有访问权，或者比较少见的多人共用同一台电脑的情况。 后者并不理想，因为你的所有代码版本库如果长存于同一台电脑，更可能发生灾难性的损失。
如果你使用共享文件系统，就可以从本地版本库克隆（clone）、推送（push）以及拉取（pull）。 像这样去克隆一个版本库或者增加一个远程到现有的项目中，使用版本库路径作为 URL。 例如，克隆一个本地版本库，可以执行如下的命令：
$ git clone /srv/git/project.git
或者
$ git clone file:///srv/git/project.git
如果在 URL 开头明确的指定 file://，那么 Git 的行为会略有不同。 如果仅是指定路径，Git 会尝试使用硬链接（hard link）或直接复制所需要的文件。 如果指定 file://，Git 会触发平时用于网路传输资料的进程，那样传输效率会更低。 指定 file:// 的主要目的是取得一个没有外部参考（extraneous references） 或对象（object）的干净版本库副本——通常是在从其他版本控制系统导入后或一些类似情况需要这么做 。 在此我们将使用普通路径，因为这样通常更快。
要增加一个本地版本库到现有的 Git 项目，可以执行如下的命令：
$ git remote add local_proj /srv/git/project.git
然后，就可以通过新的远程仓库名 local_proj 像在网络上一样从远端版本库推送和拉取更新了。
优点
基于文件系统的版本库的优点是简单，并且直接使用了现有的文件权限和网络访问权限。 如果你的团队已经有共享文件系统，建立版本库会十分容易。 只需要像设置其他共享目录一样，把一个裸版本库的副本放到大家都可以访问的路径，并设置好读/写的权限，就可以了， 我们会在 在服务器上搭建 Git 讨论如何导出一个裸版本库。
这也是快速从别人的工作目录中拉取更新的方法。 如果你和别人一起合作一个项目，他想让你从版本库中拉取更新时，运行类似 git pull /home/john/project 的命令比推送到服务器再抓取回来简单多了。
缺点
这种方法的缺点是，通常共享文件系统比较难配置，并且比起基本的网络连接访问，这不方便从多个位置访问。 如果你想从家里推送内容，必须先挂载一个远程磁盘，相比网络连接的访问方式，配置不方便，速度也慢。
值得一提的是，如果你使用的是类似于共享挂载的文件系统时，这个方法不一定是最快的。 访问本地版本库的速度与你访问数据的速度是一样的。 在同一个服务器上，如果允许 Git 访问本地硬盘，一般的通过 NFS 访问版本库要比通过 SSH 访问慢。
最终，这个协议并不保护仓库避免意外的损坏。 每一个用户都有“远程”目录的完整 shell 权限，没有方法可以阻止他们修改或删除 Git 内部文件和损坏仓库。
2.2 HTTP 协议
Git 通过 HTTP 通信有两种模式。 在 Git 1.6.6 版本之前只有一个方式可用，十分简单并且通常是只读模式的。 Git 1.6.6 版本引入了一种新的、更智能的协议，让 Git 可以像通过 SSH 那样智能的协商和传输数据。 之后几年，这个新的 HTTP 协议因为其简单、智能变的十分流行。 新版本的 HTTP 协议一般被称为 智能 HTTP 协议，旧版本的一般被称为 哑 HTTP 协议。 我们先了解一下新的智能 HTTP 协议。
智能 HTTP 协议
智能 HTTP 的运行方式和 SSH 及 Git 协议类似，只是运行在标准的 HTTP/S 端口上并且可以使用各种 HTTP 验证机制， 这意味着使用起来会比 SSH 协议简单的多，比如可以使用 HTTP 协议的用户名/密码授权，免去设置 SSH 公钥。
智能 HTTP 协议或许已经是最流行的使用 Git 的方式了，它即支持像 git:// 协议一样设置匿名服务， 也可以像 SSH 协议一样提供传输时的授权和加密。 而且只用一个 URL 就可以都做到，省去了为不同的需求设置不同的 URL。 如果你要推送到一个需要授权的服务器上（一般来讲都需要），服务器会提示你输入用户名和密码。 从服务器获取数据时也一样。
事实上，类似 GitHub 的服务，你在网页上看到的 URL（比如 https://github.com/schacon/simplegit）， 和你在克隆、推送（如果你有权限）时使用的是一样的。
哑(Dumb)HTTP协议
如果服务器没有提供智能 HTTP 协议的服务，Git 客户端会尝试使用更简单的“哑” HTTP 协议。 哑 HTTP 协议里 web 服务器仅把裸版本库当作普通文件来对待，提供文件服务。 哑 HTTP 协议的优美之处在于设置起来简单。 基本上，只需要把一个裸版本库放在 HTTP 根目录，设置一个叫做 post-update 的挂钩就可以了 （见 Git 钩子）。 此时，只要能访问 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
这样就可以了。 Git 自带的 post-update 挂钩会默认执行合适的命令（git update-server-info），来确保通过 HTTP 的获取和克隆操作正常工作。 这条命令会在你通过 SSH 向版本库推送之后被执行；然后别人就可以通过类似下面的命令来克隆：
$ git clone https://example.com/gitproject.git
这里我们用了 Apache 里设置了常用的路径 /var/www/htdocs，不过你可以使用任何静态 Web 服务器 —— 只需要把裸版本库放到正确的目录下就可以。 Git 的数据是以基本的静态文件形式提供的（详情见 Git 内部原理）。
通常的，会在可以提供读／写的智能 HTTP 服务和简单的只读的哑 HTTP 服务之间选一个。 极少会将二者混合提供服务。
优点
我们将只关注智能 HTTP 协议的优点。
不同的访问方式只需要一个 URL 以及服务器只在需要授权时提示输入授权信息，这两个简便性让终端用户使用 Git 变得非常简单。 相比 SSH 协议，可以使用用户名／密码授权是一个很大的优势，这样用户就不必须在使用 Git 之前先在本地生成 SSH 密钥对再把公钥上传到服务器。 对非资深的使用者，或者系统上缺少 SSH 相关程序的使用者，HTTP 协议的可用性是主要的优势。 与 SSH 协议类似，HTTP 协议也非常快和高效。
你也可以在 HTTPS 协议上提供只读版本库的服务，如此你在传输数据的时候就可以加密数据；或者，你甚至可以让客户端使用指定的 SSL 证书。
另一个好处是 HTTPS 协议被广泛使用，一般的企业防火墙都会允许这些端口的数据通过。
缺点
在一些服务器上，架设 HTTPS 协议的服务端会比 SSH 协议的棘手一些。 除了这一点，用其他协议提供 Git 服务与智能 HTTP 协议相比就几乎没有优势了。
如果你在 HTTP 上使用需授权的推送，管理凭证会比使用 SSH 密钥认证麻烦一些。 然而，你可以选择使用凭证存储工具，比如 macOS 的 Keychain 或者 Windows 的凭证管理器。 参考 凭证存储 如何安全地保存 HTTP 密码。
2.3 SSH 协议
架设 Git 服务器时常用 SSH 协议作为传输协议。 因为大多数环境下服务器已经支持通过 SSH 访问 —— 即使没有也很容易架设。 SSH 协议也是一个验证授权的网络协议；并且，因为其普遍性，架设和使用都很容易。
通过 SSH 协议克隆版本库，你可以指定一个 ssh:// 的 URL：
$ git clone ssh://[user@]server/project.git
或者使用一个简短的 scp 式的写法：
$ git clone [user@]server:project.git
在上面两种情况中，如果你不指定可选的用户名，那么 Git 会使用当前登录的用的名字。
优势
用 SSH 协议的优势有很多。 首先，SSH 架设相对简单 —— SSH 守护进程很常见，多数管理员都有使用经验，并且多数操作系统都包含了它及相关的管理工具。 其次，通过 SSH 访问是安全的 —— 所有传输数据都要经过授权和加密。 最后，与 HTTPS 协议、Git 协议及本地协议一样，SSH 协议很高效，在传输前也会尽量压缩数据。
缺点
SSH 协议的缺点在于它不支持匿名访问 Git 仓库。 如果你使用 SSH，那么即便只是读取数据，使用者也 必须 通过 SSH 访问你的主机， 这使得 SSH 协议不利于开源的项目，毕竟人们可能只想把你的仓库克隆下来查看。 如果你只在公司网络使用，SSH 协议可能是你唯一要用到的协议。 如果你要同时提供匿名只读访问和 SSH 协议，那么你除了为自己推送架设 SSH 服务以外， 还得架设一个可以让其他人访问的服务。
2.4 Git 协议
最后是 Git 协议。 这是包含在 Git 里的一个特殊的守护进程；它监听在一个特定的端口（9418），类似于 SSH 服务，但是访问无需任何授权。 要让版本库支持 Git 协议，需要先创建一个 git-daemon-export-ok 文件 —— 它是 Git 协议守护进程为这个版本库提供服务的必要条件 —— 但是除此之外没有任何安全措施。 要么谁都可以克隆这个版本库，要么谁也不能。 这意味着，通常不能通过 Git 协议推送。 由于没有授权机制，一旦你开放推送操作，意味着网络上知道这个项目 URL 的人都可以向项目推送数据。 不用说，极少会有人这么做。
优点
目前，Git 协议是 Git 使用的网络传输协议里最快的。 如果你的项目有很大的访问量，或者你的项目很庞大并且不需要为写进行用户授权，架设 Git 守护进程来提供服务是不错的选择。 它使用与 SSH 相同的数据传输机制，但是省去了加密和授权的开销。
缺点
Git 协议缺点是缺乏授权机制。 把 Git 协议作为访问项目版本库的唯一手段是不可取的。 一般的做法里，会同时提供 SSH 或者 HTTPS 协议的访问服务，只让少数几个开发者有推送（写）权限，其他人通过 git:// 访问只有读权限。 Git 协议也许也是最难架设的。 它要求有自己的守护进程，这就要配置 xinetd、systemd 或者其他的程序，这些工作并不简单。 它还要求防火墙开放 9418 端口，但是企业防火墙一般不会开放这个非标准端口。 而大型的企业防火墙通常会封锁这个端口。
03. 在服务器上搭建git
在开始架设 Git 服务器前，需要把现有仓库导出为裸仓库——即一个不包含当前工作目录的仓库。 这通常是很简单的。 为了通过克隆你的仓库来创建一个新的裸仓库，你需要在克隆命令后加上 --bare 选项。 按照惯例，裸仓库的目录名以 .git 结尾，就像这样：
deng@local:~/test/project$ git init
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/deng/test/project/.git/
deng@local:~/test/project$ git add *
deng@local:~/test/project$ git commit -m "初始化项目"
[master （根提交） 09caa6d] 初始化项目
215 files changed, 33668 insertions(+)
deng@local:~/test$ git clone --bare project project.git
克隆到纯仓库 'project.git'...
完成。
deng@local:~/test$
现在，你的 project.git 目录中应该有 Git 目录的副本了。
整体上效果大致相当于
$ cp -Rf project/.git project.git
虽然在配置文件中有若干不同，但是对于你的目的来说，这两种方式都是一样的。 它只取出 Git 仓库自身，不要工作目录，然后特别为它单独创建一个目录。
04. 把裸仓库放到服务器上
既然你有了裸仓库的副本，剩下要做的就是把裸仓库放到服务器上并设置你的协议。 假设一个域名为 deng.com 的服务器已经架设好，并可以通过 SSH 连接， 你想把所有的 Git 仓库放在 /home/deng/git/ 目录下。 假设服务器上存在 /home/deng/git/ 目录，你可以通过以下命令复制你的裸仓库来创建一个新仓库：
deng@local:~/test$ scp -r project.git [email protected]:/home/deng/git
The authenticity of host 'deng.com (10.36.100.57)' can't be established.
ED25519 key fingerprint is SHA256:/nUDhkdz+kuI350kWGwCt0rv4HvTjjlKDtgLO2WjvvI.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'deng.com' (ED25519) to the list of known hosts.
[email protected]'s password:
此时，其他可通过 SSH 读取此服务器上 /srv/git 目录的用户，可运行以下命令来克隆你的仓库。
deng@local:~/tmp$ git clone [email protected]:/home/deng/git/project.git
正克隆到 'project'...
[email protected]'s password:
remote: 枚举对象中: 241, 完成.
remote: 对象计数中: 100% (241/241), 完成.
remote: 压缩对象中: 100% (235/235), 完成.
remote: 总共 241（差异 55），复用 0（差异 0），包复用 0
接收对象中: 100% (241/241), 382.87 KiB | 7.36 MiB/s, 完成.
处理 delta 中: 100% (55/55), 完成.
deng@local:~/tmp$
如果一个用户，通过使用 SSH 连接到一个服务器，并且其对 /home/deng/git/my_project.git 目录拥有可写权限，那么他将自动拥有推送权限。
如果到该项目目录中运行 git init 命令，并加上 --shared 选项， 那么 Git 会自动修改该仓库目录的组权限为可写。 注意，运行此命令的工程中不会摧毁任何提交、引用等内容。
deng@local:~/tmp$ ssh [email protected]
[email protected]'s password:
Last login: Tue Sep 12 20:01:49 2023 from 10.36.100.56
deng@local:~$ cd /home/deng/git/project.git/
deng@local:~/git/project.git$ git init --bare --shared
重新初始化已存在的共享 Git 仓库于 /home/deng/git/project.git/
deng@local:~/git/project.git$
由此可见，根据现有的 Git 仓库创建一个裸仓库，然后把它放上你和协作者都有 SSH 访问权的服务器是多么容易。 现在你们已经准备好在同一项目上展开合作了。
值得注意的是，这的确是架设一个几个人拥有连接权的 Git 服务的全部—— 只要在服务器上加入可以用 SSH 登录的帐号，然后把裸仓库放在大家都有读写权限的地方。 你已经准备好了一切，无需更多。
小型安装
如果设备较少或者你只想在小型开发团队里尝试 Git ，那么一切都很简单。 架设 Git 服务最复杂的地方在于用户管理。 如果需要仓库对特定的用户可读，而给另一部分用户读写权限，那么访问和许可安排就会比较困难。
SSH 连接
如果你有一台所有开发者都可以用 SSH 连接的服务器，架设你的第一个仓库就十分简单了， 因为你几乎什么都不用做（正如我们上一节所说的）。 如果你想在你的仓库上设置更复杂的访问控制权限，只要使用服务器操作系统的普通的文件系统权限就行了。
如果需要团队里的每个人都对仓库有写权限，又不能给每个人在服务器上建立账户，那么提供 SSH 连接就是唯一的选择了。 我们假设用来共享仓库的服务器已经安装了 SSH 服务，而且你通过它访问服务器。
有几个方法可以使你给团队每个成员提供访问权。 第一个就是给团队里的每个人创建账号，这种方法很直接但也很麻烦。 或许你不会想要为每个人运行一次 adduser（或者 useradd）并且设置临时密码。
第二个办法是在主机上建立一个 ‘git’ 账户，让每个需要写权限的人发送一个 SSH 公钥， 然后将其加入 git 账户的 ~/.ssh/authorized_keys 文件。 这样一来，所有人都将通过 ‘git’ 账户访问主机。 这一点也不会影响提交的数据——访问主机用的身份不会影响提交对象的提交者信息。
另一个办法是让 SSH 服务器通过某个 LDAP 服务，或者其他已经设定好的集中授权机制，来进行授权。 只要每个用户可以获得主机的 shell 访问权限，任何 SSH 授权机制你都可视为是有效的。
05. 生成SSH公钥
如前所述，许多 Git 服务器都使用 SSH 公钥进行认证。 为了向 Git 服务器提供 SSH 公钥，如果某系统用户尚未拥有密钥，必须事先为其生成一份。 这个过程在所有操作系统上都是相似的。 首先，你需要确认自己是否已经拥有密钥。 默认情况下，用户的 SSH 密钥存储在其 ~/.ssh 目录下。 进入该目录并列出其中内容，你便可以快速确认自己是否已拥有密钥：
deng@local:~/.ssh$ ssh-keygen -o
Generating public/private rsa key pair.
Enter file in which to save the key (/home/deng/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/deng/.ssh/id_rsa
Your public key has been saved in /home/deng/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:7Jo/oxphIEXxRhwJImFBxJBoniGEMj4lKdKAq2W8SD4 deng@local
The key's randomart image is:
+---[RSA 3072]----+
|/%B+oo |
|&O.+o |
|X+* o |
|.B+o . |
|++..o S |
|oE.. . . |
| . . . |
| . oo |
| ..+o.o |
+----[SHA256]-----+
deng@local:~/.ssh$
我们需要寻找一对以 id_dsa 或 id_rsa 命名的文件，其中一个带有 .pub 扩展名。 .pub 文件是你的公钥，另一个则是与之对应的私钥。 如果找不到这样的文件（或者根本没有 .ssh 目录），你可以通过运行 ssh-keygen 程序来创建它们。 在 Linux/macOS 系统中，ssh-keygen 随 SSH 软件包提供。
deng@local:~/.ssh$ ls
id_rsa id_rsa.pub known_hosts known_hosts.old
deng@local:~/.ssh$
首先 ssh-keygen 会确认密钥的存储位置（默认是 .ssh/id_rsa），然后它会要求你输入两次密钥口令。 如果你不想在使用密钥时输入口令，将其留空即可。 然而，如果你使用了密码，那么请确保添加了 -o 选项，它会以比默认格式更能抗暴力破解的格式保存私钥。 你也可以用 ssh-agent 工具来避免每次都要输入密码。
现在，进行了上述操作的用户需要将各自的公钥发送给任意一个 Git 服务器管理员 （假设服务器正在使用基于公钥的 SSH 验证设置）。 他们所要做的就是复制各自的 .pub 文件内容，并将其通过邮件发送。 公钥看起来是这样的：
deng@local:~/.ssh$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCpeZghbilXBoaqnvU8RF7tWr/RT9NyYZDEuZSOeCPThPq8Y17XA/Kq2lgmHQ9YjZWvw0TxeBSA7YxuntXiw+8oGBw789LXRXxPsZI2FCi6oJPwtm6VCzVEt+t2QXPpg7t9l0l3y2ZXvgL2g5oUpfrrBd/mXuR5XoBdLOi2JobIdaUT02sn1y7kLJeigLitMPK0RloQ9znELTvmbzLBbS+07eiErcerYcavPrDQzOenvraA8md9G+JuKlNBJ9WoxfkCdLPS8TVuO5xlEinFxZB3fu18LefNiuHmhuhKKO+503nwr76/d/V26Sx519/s/5JyjNlskoCWJ/uKUxkGSviwBQS9CoR8nnatZfM5OVgVtoizgX9zFJrg3NUCKC5Y+HWiRv1WWGzO20fXy9JKAkiIAJbSUv3sgfUOFlUzzkTWa0KBZk5DSf3oLKpgZK0hwKYyCYIQsynTfpLfIk9GXtp7/HW5TodYjZl7yLyby/qUpzuV3AHoqomXzYKkghomTpE= deng@local
deng@local:~/.ssh$
关于在多种操作系统中生成 SSH 密钥的更深入教程，请参阅 GitHub 的 SSH 密钥指南 https://docs.github.com/cn/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent。
06. 配置服务器
我们来看看如何配置服务器端的 SSH 访问。 本例中，我们将使用 authorized_keys 方法来对用户进行认证。 同时我们假设你使用的操作系统是标准的 Linux 发行版，比如 Ubuntu。 首先，创建一个操作系统用户 git，并为其建立一个 .ssh 目录。
首先，创建一个操作系统用户 git，并为其建立一个 .ssh 目录。
deng@local:~/tmp$ sudo adduser git
adduser：用户"git"已经存在。
deng@local:~/tmp$ su - git
密码：
git@local:~$ cd
git@local:~$ mkdir .ssh && chmod 700 .ssh
git@local:~$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
git@local:~$
将这些公钥加入系统用户 git 的 .ssh 目录下 authorized_keys 文件的末尾：
git@local:~$ cat /tmp/id_rsa_deng.pub >> ~/.ssh/authorized_keys
git@local:~$
现在我们来为开发者新建一个空仓库。可以借助带 --bare 选项的 git init 命令来做到这一点，该命令在初始化仓库时不会创建工作目录：
git@local:~$ mkdir project.git
git@local:~$ cd project.git/
git@local:~/project.git$ git init --bare
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/git/project.git/
git@local:~/project.git$
接着可以将他们项目的最初版本推送到这个仓库中， 他只需将此仓库设置为项目的远程仓库并向其推送分支。 请注意，每添加一个新项目，都需要有人登录服务器取得 shell，并创建一个裸仓库。 我们假定这个设置了 git 用户和 Git 仓库的服务器使用 gitserver 作为主机名。 同时，假设该服务器运行在内网，并且你已在 DNS 配置中将 gitserver 指向此服务器。 那么我们可以运行如下命令（假定 myproject 是已有项目且其中已包含文件）：
deng@local:~/test$ cd project
deng@local:~/test/project$ ls
appveyor.yml cJSON_Utils.c fuzzing README.md
CHANGELOG.md cJSON_Utils.h library_config test.c
cJSON.c CMakeLists.txt LICENSE tests
cJSON.h CONTRIBUTORS.md Makefile valgrind.supp
deng@local:~/test/project$ git init
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/deng/test/project/.git/
deng@local:~/test/project$ git add *
deng@local:~/test/project$ git commit -m "初始化项目"
[master （根提交） 66842fc] 初始化项目
215 files changed, 33668 insertions(+)
deng@local:~/test/project$ git remote add origin [email protected]:/home/git/project.git
deng@local:~/test/project$ git push origin master
The authenticity of host 'git.com (10.36.100.57)' can't be established.
ED25519 key fingerprint is SHA256:/nUDhkdz+kuI350kWGwCt0rv4HvTjjlKDtgLO2WjvvI.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
~/.ssh/known_hosts:14: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'git.com' (ED25519) to the list of known hosts.
枚举对象中: 241, 完成.
对象计数中: 100% (241/241), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (235/235), 完成.
写入对象中: 100% (241/241), 384.45 KiB | 6.63 MiB/s, 完成.
总共 241（差异 53），复用 0（差异 0），包复用 0
remote: 处理 delta 中: 100% (53/53), 完成.
To git.com:/home/git/project.git
* [new branch] master -> master
deng@local:~/test/project$
此时，其他开发者可以克隆此仓库，并推回各自的改动，步骤很简单：
deng@local:~/test/tmp$ git clone [email protected]:/home/git/project.git
正克隆到 'project'...
remote: 枚举对象中: 241, 完成.
remote: 对象计数中: 100% (241/241), 完成.
remote: 压缩对象中: 100% (182/182), 完成.
remote: 总共 241（差异 53），复用 241（差异 53），包复用 0
接收对象中: 100% (241/241), 384.45 KiB | 7.25 MiB/s, 完成.
处理 delta 中: 100% (53/53), 完成.
deng@local:~/test/tmp$ cd project/
deng@local:~/test/tmp/project$ ls
appveyor.yml cJSON_Utils.c fuzzing README.md
CHANGELOG.md cJSON_Utils.h library_config test.c
cJSON.c CMakeLists.txt LICENSE tests
cJSON.h CONTRIBUTORS.md Makefile valgrind.supp
deng@local:~/test/tmp/project$ vim README.md
deng@local:~/test/tmp/project$ git commit -a -m "fix the bug"
[master 7e444e8] fix the bug
1 file changed, 1 insertion(+)
deng@local:~/test/tmp/project$ git push origin master
枚举对象中: 5, 完成.
对象计数中: 100% (5/5), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 283 字节 | 283.00 KiB/s, 完成.
总共 3（差异 2），复用 0（差异 0），包复用 0
To git.com:/home/git/project.git
66842fc..7e444e8 master -> master
deng@local:~/test/tmp/project$
通过这种方法，你可以快速搭建一个具有读写权限、面向多个开发者的 Git 服务器。
需要注意的是，目前所有（获得授权的）开发者用户都能以系统用户 git 的身份登录服务器从而获得一个普通 shell。 如果你想对此加以限制，则需要修改 /etc/passwd 文件中（git 用户所对应）的 shell 值。
借助一个名为 git-shell 的受限 shell 工具，你可以方便地将用户 git 的活动限制在与 Git 相关的范围内。 该工具随 Git 软件包一同提供。如果将 git-shell 设置为用户 git 的登录 shell（login shell）， 那么该用户便不能获得此服务器的普通 shell 访问权限。 若要使用 git-shell，需要用它替换掉 bash 或 csh，使其成为该用户的登录 shell。 为进行上述操作，首先你必须确保 git-shell 的完整路径名已存在于 /etc/shells 文件中：
$ cat /etc/shells # see if git-shell is already in there. If not...
$ which git-shell # make sure git-shell is installed on your system.
$ sudo -e /etc/shells # and add the path to git-shell from last command
现在你可以使用 chsh <username> -s <shell> 命令修改任一系统用户的 shell：
$ sudo chsh git -s $(which git-shell)
这样，用户 git 就只能利用 SSH 连接对 Git 仓库进行推送和拉取操作，而不能登录机器并取得普通 shell。 如果试图登录，你会发现尝试被拒绝，像这样：
$ ssh [email protected]
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
此时，用户仍可通过 SSH 端口转发来访问任何可达的 git 服务器。 如果你想要避免它，可编辑 authorized_keys 文件并在所有想要限制的公钥之前添加以下选项：
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
其结果如下：
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
现在，网络相关的 Git 命令依然能够正常工作，但是开发者用户已经无法得到一个普通 shell 了。 正如输出信息所提示的，你也可以在 git 用户的主目录下建立一个目录，来对 git-shell 命令进行一定程度的自定义。 比如，你可以限制掉某些本应被服务器接受的 Git 命令，或者对刚才的 SSH 拒绝登录信息进行自定义，这样，当有开发者用户以类似方式尝试登录时，便会看到你的信息。 要了解更多有关自定义 shell 的信息，请运行 git help shell。