协议概述
Git共享服务的实现方式大致分为四种：文件共享类型、git类型、ssh类型、http类型；
本地协议
本地协议：文件共享类型，是对Git项目，通过文件共享的方式；如NFS、FTP、samba、san、ISCSI等方式进行Git项目共享；比如这样：git clone /opt/git/project.git，又或者是这样：git clone file：///opt/git/project.git。如果在URL开头中使用了file：//，那么git会以一种略微不同的方式运行。如果你只给出路径，Git 会尝试使用硬链接或直接复制它所需要的文件。如果使用了 file:// ，Git 会调用它平时通过网络来传输数据的工序，而这种方式的效率相对较低。使用 file:// 前缀的主要原因是当你需要一个不包含无关引用或对象的干净仓库副本的时候 — 一般指从其他版本控制系统导入的，或类似情形。
优点：简单粗暴、保留原有文件的权限
缺点：很难控制从不同位置的访问权限、且速度受共享协议的限制
SSH协议
ssh协议：Git项目共享中使用最常见的协议估计就是SSH了。这是因为大多数环境已经支持SSH对服务器的访问，就算没有，架设起来也很容易。SSH 也是唯一一个同时支持读写操作的网络协议。另外两个网络协议（HTTP 和 Git）通常都是只读的，所以虽然二者对大多数人都可用，但执行写操作时还是需要 SSH。SSH 同时也是一个验证授权的网络协议；而因为其普遍性，一般架设和使用都很容易。通过SSH克隆一个Git仓库，你可以像下面这样给出ssh：//的URL：git clone ssh：//user@server/project.git或者git clone user@server：project.git。如果不指名用户，Git默认会使用当前用户连接；如果不指名协议，Git会默认采用ssh协议进行传输。
优点：同时读写、架设相对简单、维护方便、传输安全、高效的传输速度
缺点：无法匿名访问
GIT协议
Git协议：这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供类似于 SSH 服务的特定端口（9418），而无需任何授权。打算支持 Git 协议的仓库，需要先创建 git-daemon-export-ok 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作；然而由于没有授权机制，一旦允许该操作，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的情况。
优点：传输速度快，甚至比SSH更加快，可匿名
缺点：缺少授权机制，不安全
HTTP/HTTPS协议
HTTP/HTTPS协议：HTTP 或 HTTPS 协议的优美之处在于架设的简便性。基本上，只需要把 Git 的裸仓库文件放在 HTTP 的根目录下，配置一个特定的 post-update 挂钩（hook）就可以搞定（Git 挂钩的细节见第 7 章）。此后，每个能访问 Git 仓库所在服务器上 web 服务的人都可以进行克隆操作。
优点：使用 HTTP 协议的好处是易于架设。几条必要的命令就可以让全世界读取到仓库的内容。花费不过几分钟。HTTP 协议不会占用过多服务器资源。因为它一般只用到静态的 HTTP 服务提供所有数据，普通的 Apache 服务器平均每秒能支撑数千个文件的并发访问 — 哪怕让一个小型服务器超载都很难。
缺点：HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者下载仓库内容可能会花费更多时间，而且 HTTP 传输的体积和网络开销比其他任何一个协议都大。因为它没有按需供应的能力 — 传输过程中没有服务端的动态计算 — 因而 HTTP 协议经常会被称为傻瓜（dumb）协议。更多 HTTP 协议和其他协议效率上的差
参考地址：http://blog.csdn.net/liangpz521/article/details/21534849
速度的比较
最快的是Git、其次是ssh、接着是本地协议、最后是http协议
安全的比较
最安全的是ssh、其次是http协议、接着本地协议、最后是git
，又或者是这样：git clone file：///opt/git/project.git。如果在URL开头中使用了file：//，那么git会以一种略微不同的方式运行。如果你只给出路径，Git 会尝试使用硬链接或直接复制它所需要的文件。如果使用了 file:// ，Git 会调用它平时通过网络来传输数据的工序，而这种方式的效率相对较低。使用 file:// 前缀的主要原因是当你需要一个不包含无关引用或对象的干净仓库副本的时候 — 一般指从其他版本控制系统导入的，或类似情形。