Git book指定GIT可以使用的四种协议：Local，HTTP，Secure Shell (SSH)和Git。我的理解是正确的，当我像这样从github克隆存储库时：
git clone https://github.com/username/test.git
我正在使用HTTP协议吗？
如果我想使用GIT协议，我需要像这样克隆存储库吗？
git clone git@github.com:maximusk/test.git
答案 0 :(得分：3)
协议未明确存储在任何地方。在使用URL（用于clone，fetch，push等）时从URL中检测到它。
克隆存储库后，将在克隆中创建名为origin的远程目录。克隆的存储库的URL设置为新克隆的fetch远程服务器的push和origin URL。
使用git remote -v查看每个遥控器的URL。
使用git remote set-url更改遥控器的URL。
您可以为fetch和push使用不同的URL，但是它们必须指向相同的远程存储库。如果您想从一个存储库fetch push到另一个存储库，则配置两个不同的remote。
答案 1 :(得分：2)
您的问题主要针对Git Pro书中的讨论，从技术上讲，这实际上是在处理我认为应称为 transports 而不是协议的内容。 Git Pro本书并未对此加以区分（至少在我撰写此答案时）；当前的Git文档也没有。但是Git 2.18 has introduced a new wire protocol（启用代码首先出现在Git 2.16中），所以我认为这需要另一个答案来证明这个问题的未来。
尤其是，Git的不良习惯是将身份验证，权限，传输（在网络堆栈）和协议（Git用于Git到Web服务器或对等通信）。到目前为止，这对于Git一直有效，因为：
file://或原始路径名）说明符导致使用本地方法，该方法不进行身份验证并且依赖于操作系统权限。 1 由于您的Git只是在自言自语，它只需要同意自己对自己所说的话即可。http://和https://指示符使用libcurl和外部身份验证器进行身份验证（如果他们完全进行身份验证）。 2 之后，它们依赖操作系统权限。由于Git与Web服务器通信，因此它必须通过服务器的REST接口走私其自己的协议。同时，Web服务器本身提供了传输协议。ssh://说明符通常使用OS提供的库中的ssh进行身份验证和传输。 3 另一端的OS在正常情况下会提供所有权限检查。 （诸如Gitolite和GitHub-ssh-access之类的特殊情况在幕后使用了其他技巧，这些都是Git权限范围之外的。）git://说明符使用TCP之上的轻量级协议作为传输协议。它不进行身份验证，也没有权限检查。它纯粹是只读的：它不需要任何东西来控制谁可以推送，因为没有人可以推送。 4 直到Git 2.16，实际上只有一种Git有线协议。 （所谓的“哑协议”特定于使用Web服务器，即使如此，仅当它们不能运行真实协议时，哑协议才真正意味着能够从Web服务器下载单个文件，就是这样。 ！）但是，在Git 2.16中，Git学会了请求特定协议版本的能力。
因此，现有的智能协议成为Git协议的零版本。 Git协议版本1立即被定义为执行相同的操作，因此可以在不添加任何其他内容的情况下测试协议版本选择代码。
但是，在Git 2.18中，现在有一个协议版本2。协议2仍在定义中，但是它的第一个（也许至少是最有用的）窍门是列出更少的引用。例如，连接到具有许多标签的大型，较旧的Git存储库可能会浪费大量带宽。 the Google blog page here有很多不错的细节。
目前，这种协议编号仍主要针对Git开发人员，但很快可能会变得重要。
1 值得一提的是，POSIX系统（Linux，各种BSD等）上的OS权限允许 user ， group 和 other 权限。在这里，“用户”是指运行各种命令的用户的数字用户ID，“组”是指数字的组ID，“其他”是指不首先匹配“用户”或“组”的任何人。也就是说，实际权限是由这三个用户中的哪个首先与当前用户的ID匹配来确定的。
虽然Git的功能不如完整的ACL，但Git却利用这些权限让OS处理本地（同一主机）和远程（任何网络传输）权限检查。具体来说，您可以将core.sharedRepository配置为group或all或连接特定的POSIX umask 值。有关详细信息，请参见the git config documentation。
2 请注意，https://可以使用SSL / TLS并进行加密的数据交换。也就是说，假设没有人破坏加密，那么REST操作以及一旦Git通过Git将使用的任何协议建立连接就发送的所有数据，对于中间站点都是保密的。 Git交付给libcurl有许多配置旋钮（尽管要由libcurl来 use 使用）。查看http.*中的所有git config设置。 SSL安全性很复杂；请参阅脚注3中的链接。
3 SSH传输通过SSL / TLS加密，尽管细节有所不同。有关更多信息，请参见Difference between SSH and SSL, especially in terms of "SFTP" vs. "FTP over SSL"。
4 与kostix noted in a comment一样，您可以启用推送git://传输。对我来说，这似乎是一个非常糟糕的主意，因为 因为没有身份验证，也没有权限检查。请注意，由于服务git://请求的Git守护进程作为一个特定的用户ID（通常为git-daemon的用户ID）运行，因此有效地缩短了OS级权限检查。