Git 使用的協(xié)議

Git 可以使用四種主要的協(xié)議來傳輸數(shù)據(jù)：本地傳輸，SSH 協(xié)議，Git 協(xié)議和 HTTP 協(xié)議。下面分別介紹一下哪些情形應該使用（或避免使用）這些協(xié)議。

值得注意的是，除了 HTTP 協(xié)議外，其他所有協(xié)議都要求在服務器端安裝并運行 Git。

本地協(xié)議

最基本的就是本地協(xié)議（Local protocol），所謂的遠程倉庫在該協(xié)議中的表示，就是硬盤上的另一個目錄。這常見于團隊每一個成員都對一個共享的文件系統(tǒng)（例如 NFS）擁有訪問權(quán)，或者比較少見的多人共用同一臺電腦的情況。后面一種情況并不安全，因為所有代碼倉庫實例都儲存在同一臺電腦里，增加了災難性數(shù)據(jù)損失的可能性。

如果你使用一個共享的文件系統(tǒng)，就可以在一個本地文件系統(tǒng)中克隆倉庫，推送和獲取。克隆的時候只需要將遠程倉庫的路徑作為 URL 使用，比如下面這樣：

$ git clone /opt/git/project.git
或者這樣：

$ git clone file:///opt/git/project.git
如果在 URL 開頭明確使用 file:// ，那么 Git 會以一種略微不同的方式運行。如果你只給出路徑，Git 會嘗試使用硬鏈接或直接復制它所需要的文件。如果使用了 file:// ，Git 會調(diào)用它平時通過網(wǎng)絡來傳輸數(shù)據(jù)的工序，而這種方式的效率相對較低。使用 file:// 前綴的主要原因是當你需要一個不包含無關(guān)引用或?qū)ο蟮母蓛魝}庫副本的時候 — 一般指從其他版本控制系統(tǒng)導入的，或類似情形（參見第 9 章的維護任務）。我們這里僅僅使用普通路徑，這樣更快。

要添加一個本地倉庫作為現(xiàn)有 Git 項目的遠程倉庫，可以這樣做：

$ git remote add local_proj /opt/git/project.git
然后就可以像在網(wǎng)絡上一樣向這個遠程倉庫推送和獲取數(shù)據(jù)了。

優(yōu)點

基于文件倉庫的優(yōu)點在于它的簡單，同時保留了現(xiàn)存文件的權(quán)限和網(wǎng)絡訪問權(quán)限。如果你的團隊已經(jīng)有一個全體共享的文件系統(tǒng)，建立倉庫就十分容易了。你只需把一份裸倉庫的副本放在大家都能訪問的地方，然后像對其他共享目錄一樣設(shè)置讀寫權(quán)限就可以了。我們將在下一節(jié)“在服務器上部署 Git ”中討論如何導出一個裸倉庫的副本。

這也是從別人工作目錄中獲取工作成果的快捷方法。假如你和你的同事在一個項目中合作，他們想讓你檢出一些東西的時候，運行類似 git pull /home/john/project 通常會比他們推送到服務器，而你再從服務器獲取簡單得多。

缺點

這種方法的缺點是，與基本的網(wǎng)絡連接訪問相比，難以控制從不同位置來的訪問權(quán)限。如果你想從家里的筆記本電腦上推送，就要先掛載遠程硬盤，這和基于網(wǎng)絡連接的訪問相比更加困難和緩慢。

另一個很重要的問題是該方法不一定就是最快的，尤其是對于共享掛載的文件系統(tǒng)。本地倉庫只有在你對數(shù)據(jù)訪問速度快的時候才快。在同一個服務器上，如果二者同時允許 Git 訪問本地硬盤，通過 NFS 訪問倉庫通常會比 SSH 慢。

SSH 協(xié)議

Git 使用的傳輸協(xié)議中最常見的可能就是 SSH 了。這是因為大多數(shù)環(huán)境已經(jīng)支持通過 SSH 對服務器的訪問 — 即便還沒有，架設(shè)起來也很容易。SSH 也是唯一一個同時支持讀寫操作的網(wǎng)絡協(xié)議。另外兩個網(wǎng)絡協(xié)議（HTTP 和 Git）通常都是只讀的，所以雖然二者對大多數(shù)人都可用，但執(zhí)行寫操作時還是需要 SSH。SSH 同時也是一個驗證授權(quán)的網(wǎng)絡協(xié)議；而因為其普遍性，一般架設(shè)和使用都很容易。

通過 SSH 克隆一個 Git 倉庫，你可以像下面這樣給出ssh:// 的 URL：

$ git clone ssh://user@server/project.git
或者不指明某個協(xié)議 — 這時 Git 會默認使用 SSH ：

$ git clone user@server:project.git
如果不指明用戶，Git 會默認使用當前登錄的用戶名連接服務器。

優(yōu)點

使用 SSH 的好處有很多。首先，如果你想擁有對網(wǎng)絡倉庫的寫權(quán)限，基本上不可能不使用 SSH。其次，SSH 架設(shè)相對比較簡單 — SSH 守護進程很常見，很多網(wǎng)絡管理員都有一些使用經(jīng)驗，而且很多操作系統(tǒng)都自帶了它或者相關(guān)的管理工具。再次，通過 SSH 進行訪問是安全的 — 所有數(shù)據(jù)傳輸都是加密和授權(quán)的。最后，和 Git 及本地協(xié)議一樣，SSH 也很高效，會在傳輸之前盡可能壓縮數(shù)據(jù)。

缺點

SSH 的限制在于你不能通過它實現(xiàn)倉庫的匿名訪問。即使僅為讀取數(shù)據(jù)，人們也必須在能通過 SSH 訪問主機的前提下才能訪問倉庫，這使得 SSH 不利于開源的項目。如果你僅僅在公司網(wǎng)絡里使用，SSH 可能是你唯一需要使用的協(xié)議。如果想允許對項目的匿名只讀訪問，那么除了為自己推送而架設(shè) SSH 協(xié)議之外，還需要支持其他協(xié)議以便他人訪問讀取。

Git 協(xié)議

接下來是 Git 協(xié)議。這是一個包含在 Git 軟件包中的特殊守護進程； 它會監(jiān)聽一個提供類似于 SSH 服務的特定端口（9418），而無需任何授權(quán)。打算支持 Git 協(xié)議的倉庫，需要先創(chuàng)建 git-daemon-export-ok 文件 — 它是協(xié)議進程提供倉庫服務的必要條件 — 但除此之外該服務沒有什么安全措施。要么所有人都能克隆 Git 倉庫，要么誰也不能。這也意味著該協(xié)議通常不能用來進行推送。你可以允許推送操作；然而由于沒有授權(quán)機制，一旦允許該操作，網(wǎng)絡上任何一個知道項目 URL 的人將都有推送權(quán)限。不用說，這是十分罕見的情況。

優(yōu)點

Git 協(xié)議是現(xiàn)存最快的傳輸協(xié)議。如果你在提供一個有很大訪問量的公共項目，或者一個不需要對讀操作進行授權(quán)的龐大項目，架設(shè)一個 Git 守護進程來供應倉庫是個不錯的選擇。它使用與 SSH 協(xié)議相同的數(shù)據(jù)傳輸機制，但省去了加密和授權(quán)的開銷。

缺點

Git 協(xié)議消極的一面是缺少授權(quán)機制。用 Git 協(xié)議作為訪問項目的唯一方法通常是不可取的。一般的做法是，同時提供 SSH 接口，讓幾個開發(fā)者擁有推送（寫）權(quán)限，其他人通過 git:// 擁有只讀權(quán)限。 Git 協(xié)議可能也是最難架設(shè)的協(xié)議。它要求有單獨的守護進程，需要定制 — 我們將在本章的 “Gitosis” 一節(jié)詳細介紹它的架設(shè) — 需要設(shè)定 xinetd 或類似的程序，而這些工作就沒那么輕松了。該協(xié)議還要求防火墻開放 9418 端口，而企業(yè)級防火墻一般不允許對這個非標準端口的訪問。大型企業(yè)級防火墻通常會封鎖這個少見的端口。

HTTP/S 協(xié)議

最后還有 HTTP 協(xié)議。HTTP 或 HTTPS 協(xié)議的優(yōu)美之處在于架設(shè)的簡便性?；旧?，只需要把 Git 的裸倉庫文件放在 HTTP 的根目錄下，配置一個特定的 post-update 掛鉤（hook）就可以搞定（Git 掛鉤的細節(jié)見第 7 章）。此后，每個能訪問 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 向倉庫推送內(nèi)容時運行；之后，其他人就可以用下面的命令來克隆倉庫：

$ git clone http://example.com/gitproject.git
在本例中，我們使用了 Apache 設(shè)定中常用的/var/www/htdocs 路徑，不過你可以使用任何靜態(tài) web 服務 — 把裸倉庫放在它的目錄里就行。 Git 的數(shù)據(jù)是以最基本的靜態(tài)文件的形式提供的（關(guān)于如何提供文件的詳情見第 9 章）。

通過 HTTP 進行推送操作也是可能的，不過這種做法不太常見，并且牽扯到復雜的 WebDAV 設(shè)定。由于很少用到，本書將略過對該內(nèi)容的討論。如果對 HTTP 推送協(xié)議感興趣，不妨打開這個地址看一下操作方法：http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt 。

通過 HTTP 推送的好處之一是你可以使用任何 WebDAV 服務器，不需要為 Git 設(shè)定特殊環(huán)境；所以如果主機提供商支持通過 WebDAV 更新網(wǎng)站內(nèi)容，你也可以使用這項功能。

優(yōu)點

使用 HTTP 協(xié)議的好處是易于架設(shè)。幾條必要的命令就可以讓全世界讀取到倉庫的內(nèi)容?；ㄙM不過幾分鐘。HTTP 協(xié)議不會占用過多服務器資源。因為它一般只用到靜態(tài)的 HTTP 服務提供所有數(shù)據(jù)，普通的 Apache 服務器平均每秒能支撐數(shù)千個文件的并發(fā)訪問 — 哪怕讓一個小型服務器超載都很難。

你也可以通過 HTTPS 提供只讀的倉庫，這意味著你可以加密傳輸內(nèi)容；你甚至可以要求客戶端使用特定簽名的 SSL 證書。一般情況下，如果到了這一步，使用 SSH 公共密鑰可能是更簡單的方案；不過也存在一些特殊情況，這時通過 HTTPS 使用帶簽名的 SSL 證書或者其他基于 HTTP 的只讀連接授權(quán)方式是更好的解決方案。

HTTP 還有個額外的好處：HTTP 是一個如此常見的協(xié)議，以至于企業(yè)級防火墻通常都允許其端口的通信。

缺點

HTTP 協(xié)議的消極面在于，相對來說客戶端效率更低?？寺』蛘呦螺d倉庫內(nèi)容可能會花費更多時間，而且 HTTP 傳輸?shù)捏w積和網(wǎng)絡開銷比其他任何一個協(xié)議都大。因為它沒有按需供應的能力 — 傳輸過程中沒有服務端的動態(tài)計算 — 因而 HTTP 協(xié)議經(jīng)常會被稱為傻瓜（dumb）協(xié)議。更多 HTTP 協(xié)議和其他協(xié)議效率上的差異見第 9 章。