哪个是更智能的 git 协议，ssh 或 git（通过 ssh）或 https 协议？
哪个高效？ SSH:// 或 Git:// （文件压缩）
我在 Git 中的理解是，git 协议很智能，因为通信两端都有协议代理来压缩文件传输，从而通过有效地使用网络带宽来实现更快的克隆。
从一本 O'Reilly 的书中，我发现了以下陈述。
For secure, authenticated connections, the Git native
protocol can be tunneled over an SSH connection using
the following URL templates:
ssh: //[user@]example.com[:port]/path/to/repo.git
ssh: //[user@]example.com/path/to/repo.git
ssh: //[user@]example.com/~user2/path/to/repo.git
ssh: //[user@]example.com/~/path/to/repo.git*
我不确定作者所说的是否是真的。他谈到 git 协议通过 SSH 建立隧道。
从我的角度来看，除非连接到 git 端口（代理端口），否则该协议不会生效。而SSH只是一种未压缩的文件传输。但根据作者的说法，如果我们使用 SSH，他说 git 协议是通过它建立隧道的。那么 SSH 在 GIT 中是否更智能呢？
冯·C， 感谢您的回答。 “网络协议（HTTP 和 Git）通常是只读的” 当您使用 --enable=receive-pack 运行守护程序时，可以使 Git 成为 rw。
以下是我的担忧。
当他们说 git 协议很智能时，他们的意思是当您执行 git clone 时，Git 服务器代理会压缩发送回客户端的数据，因此克隆应该更快。在我的用例中，我将在香港设置 Git 服务器，并在圣何塞和其他国家/地区使用它，因此，由于延迟问题，我希望通过网络提高效率。
所以我的问题是，当我使用 git clone ssh://user@server/reposloc 时，我是否也能获得 git 协议的好处？根据 O'Reilly 作者的书，他的意思是 git 通过 ssh 建立隧道，那么当我没有在服务器上运行 git 守护进程时，git 协议如何工作。
那么使用 SSh://xyz...它是否同时具有 ssh 和 git 协议的优点？
提前感谢您的回答。
Which is efficient? SSH:// or Git:// (File compression)
I understand in Git, git protocol is smart because there is a protocol agent on both ends of communication to compress the file transfer resulting in faster clone by efficiently using the network bandwidth.
From an O'Reilly book I found the following statements.
For secure, authenticated connections, the Git native
protocol can be tunneled over an SSH connection using
the following URL templates:
ssh: //[user@]example.com[:port]/path/to/repo.git
ssh: //[user@]example.com/path/to/repo.git
ssh: //[user@]example.com/~user2/path/to/repo.git
ssh: //[user@]example.com/~/path/to/repo.git*
I'm not sure if the author means what he says. He talks of git protocol getting tunneled over SSH.
From my perspective, unless you connect to the git port (agent port), the protocol is not in effect. And SSH is merely an uncompressed file transfer. But as per the author, if we use SSH he says the git protocol is tunneled over it. So is SSH smarter in GIT?
Von C,
Thanks for your answer. "Network protocols (HTTP and Git) are generally read-only" Git can be made rw when you run the daemon with --enable=receive-pack.
Following are my concerns.
When they say git protocol is smart, they mean when you execute git clone, Git server agent compresses the data that is sent back to the client, so the clone should be faster. In my use case I'll be setting the Git server in Hongkong and using it on San Jose and other countries as well, So I want to be efficient over network due to latency concerns.
So my question is when I use git clone ssh://user@server/reposloc do I get the benefits of git protocol also? As per O'Reilly author book he means git is tunneled over ssh, then how does git protocol work when I don't have git daemon running on the server.
So using SSh://xyz... does it give both the benefit of ssh and git protocols?
Appreciate your answers in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
2010-2014 更新：
自从 Git 1.6.6+ (2010) 和 智能 http 的实现以来，ssh 和 https 是等效的协议：
您现在可以使用 ssh 或 https 来读/写访问您的回购协议。
您还可以检测您的远程服务器是否支持智能http。
如果必须使用代理，请添加正确的环境变量。
2015 年第 3 季度，Yousha Aleayoub 提到评论中：
GitHub "我应该使用哪个远程 URL？"
git-http-backend是：原始答案（2010 年 7 月）：
来自 Pro Git Book：
所以它并不比 Git 协议“更智能”，只是对 Git 协议未解决的某些功能的补充协议。
（这就是为什么在我的商店中，我需要使用 ssh+git 而不仅仅是 git，即使是读取访问：9418 被阻止...）
Update 2010-2014:
Both ssh and https are equivalent, since Git 1.6.6+ (2010) and the implementation of smart http protocol:
You now can use ssh or https for read/write access to your repos.
You can also detect if your remote server supports smart http.
Add the right environment variable if you have to use a proxy.
Q3 2015, as Yousha Aleayoub mentions in the comments:
GitHub "Which remote URL should I use?"
The
git-http-backendis the:Original answer (July 2010):
From the Pro Git Book:
So it is not "smarter" than Git protocol, just a complementary protocol for certain features not addressed by the Git protocol.
(that is why in my shop, I need to use ssh+git and not just git, even for read access: 9418 is blocked...)
看看此页面的第二部分
唯一的“ “dumb”协议是直接的 HTTP，不需要在服务器上做任何特殊的工作。在 git:// 和 ssh:// 协议中，都会在与运行 git 的客户端进行通信的服务器上分叉一个 git upload-pack 进程（不是守护进程）获取包。在 ssh:// 和 git:// 中，您可以获得“智能”通信。
Take a look at the second part of this page
The only "dumb" protocol is straight HTTP, which requires no special effort on the server. In both the git:// and ssh:// protocols, a
git upload-packprocess (which is not a daemon) is forked on the server that communicates with the client who's runninggit fetch-pack. In both ssh:// and git://, you get "smart" communication.（我想在@erjian的回答中添加评论，但我不允许，因为我没有足够的StackOverflow声誉。）
看来从Git 1.6.6开始，HTTP不再是“哑巴”了。来自 Git 网站的博客：
(I wanted to add a comment to @erjiang answer, but I'm not allowed because I don't have enough StackOverflow reputation.)
It seems that since Git 1.6.6, HTTP is not "dumb" anymore. From Git website's blog:
当您通过 ssh 访问 git 时，它只是通过 ssh 隧道传输 git 协议，这样更容易设置且更安全，这是访问远程存储库的首选方式。
这实际上比裸 git 协议“更智能”，因为它可以通过 ssh 机制强制执行用户身份验证。无论传输层如何，git 都会完成所有压缩以及不在客户端上进行的压缩，并在服务器上对其进行解压缩。
“git”服务器不会这样做，所有这一切在使用 ssh 时也会发生。如果您希望能够写入远程存储库，则应避免使用 git 服务器。如果你想只读访问 git 或 HTTP 传输是“OK”，但如果你有开发人员需要写入存储库，你应该使用 ssh。为 git 服务器设置隧道只会增加复杂性和配置，这会很脆弱并且不会给你带来任何好处。
When you access git over ssh it just tunnels the git protocol over ssh, way easier to set up and way more secure, this the preferred way to access remote repositories.
This is actually "smarter" than the bare git protocol, because it can enforce user authentication via ssh mechanisms. git does all the compressing and what not on the client regardless of the transport layer, and it decompresses it on the server.
The "git" server doesn't do this, all this happens when using ssh as well. the git server should be avoided if you want to be able to write to the remote repository. if you want read only access git or HTTP transports are "OK", but if you have developers that need to write to the respository you should just use ssh. Setting up tunnels for the git server is just adding to complexity and configuration that will be brittle and gain you nothing.
来自维基百科：
如果您需要某种 ASCII 艺术表示形式：
From Wikipedia:
If you need some kind of ASCII art representation:
各种协议处于不同的级别（例如 ISO 7 层模型），因此您可以同时拥有两者，就像您可以通过有线或无线或光纤进行连接一样。
The various protocols are at different levels (e.g. the ISO 7 layer model), so you can have both, just as you could be connected by Wires or Wirelessly, or fibre.
在 git 克隆期间快速搜索包文件将列出从服务器发送到客户端的单个包文件。包文件列在 .git/objects/pack/pack-XXXX.pack 下。从服务器发送到客户端的文件首先被打包、压缩。然后是打包内容的单个副本。在服务器端使用 lsof -p 与客户端使用 lsof -p 比较打包文件时可以看出这一点。在示例案例中，200MB的文件从服务器上传到客户端......
A quick search of the pack files during a git clone will list a single pack file that is sent from the server to the client. The pack file is listed under .git/objects/pack/pack-XXXX.pack. The files to be sent from the server to the client are first packed, compressed. Then there is a single copy of the packed contents. This can be seen when comparing the packed files using lsof -p on the server side and lsof -p on the client side. In the sample case a 200MB files is uploaded from the server to the client....