哪个有效？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协议是通过它进行隧道传输的.那么在GIT中SSH更智能吗？
冯C,谢谢你的回答."网络协议(HTTP和Git)通常是只读的"Git可以rw在你运行deamon时制作--enable=receive-pack.
以下是我的担忧.
当他们说git协议是智能的时,他们就意味着当你执行git clone时,git服务器代理会压缩发送回客户端的数据,因此克隆应该更快.在我的用例中,我将在香港设置git服务器并在圣何塞和其他国家使用它.因此,我希望由于延迟问题而在网络上保持高效.
所以我的问题是,当我使用时,我git clone ssh://user@server/reposloc也获得了git协议的好处吗？根据O'Reilly作者的书,他的意思是git通过ssh进行隧道传输,那么当我没有在服务器上运行git守护进程时,git协议如何工作.
所以使用SSh:// xyz ...它是否同时给出了ssh和git协议的好处？
提前感谢您的答案.
2010-2014更新:
自Git 1.6.6+(2010)和智能http协议的实现以来,ssh和https都是等价的:
您现在可以使用ssh或https对您的存储库进行读/写访问.
您还可以检测远程服务器是否支持智能http.
如果必须使用代理,请添加正确的环境变量.
2015年第3季度,Yousha Aleayoub 在评论中提到:
GitHub"我应该使用哪个远程URL？"
该
https://克隆网址,可在所有存储库,公共和私人.
它们很智能,因此它们将为您提供只读或读/写访问权限,具体取决于您对存储库的权限.
这git-http-backend是:
简单的CGI程序,用于向Git客户端提供访问存储库
http://和https://协议的Git存储库的内容.
该程序支持客户端使用智能HTTP协议和向后兼容的哑HTTP协议以及使用智能HTTP协议推送的客户端.
原始答案(2010年7月):
来自Pro Git Book:
可能最常见的Git传输协议是SSH.
这是因为在大多数地方已经建立了对服务器的SSH访问 - 如果不是这样,那么很容易做到.SSH也是唯一可以轻松读取和写入的基于网络的协议.另外两个网络协议(HTTP和Git)通常是只读的,所以即使你有可用于未洗涤的群体,你仍然需要SSH来处理你自己的写命令.
SSH也是经过身份验证的网络协议 ; 因为它无处不在,所以通常很容易设置和使用.
因此它不比Git协议"更智能",只是Git协议未解决的某些功能的补充协议.
Git协议的缺点是缺乏身份验证.通常不希望Git协议成为您项目的唯一访问权限.
通常,您将为具有推送(写入)访问权限并且其他所有人都使用git://只读访问权限的少数开发人员将其与SSH访问配对它还需要防火墙访问端口9418,这不是企业防火墙始终允许的标准端口.在大型企业防火墙的背后,这个不起眼的端口通常被阻止.
(这就是为什么在我的商店,我需要使用ssh + git而不仅仅是git,即使是读取权限:9418 被阻止...)
看一下本页的第二部分
唯一的"哑"协议是直接HTTP,在服务器上不需要特别的努力.在git://和ssh://协议中,git upload-pack进程(不是守护进程)分叉在与正在运行的客户端通信的服务器上git fetch-pack.在ssh://和git://中,您都可以进行"智能"通信.
京公网安备 11010802040832号 | 京ICP备19059560号-6 