協議

Git 可以使用四種主要的協議來傳輸資料：本地傳輸，SSH 協議，Git 協議和 HTTP 協議。下面分別介紹一下哪些情形應該使用（或避免使用）這些協議。

值得注意的是，除了 HTTP 協議外，其他所有協議都要求在伺服器端安裝並執行 Git。

本地協議

最基本的就是_本地協議（Local protocol）_，所謂的遠端倉庫在該協議中的表示，就是硬碟上的另一個目錄。這常見於團隊每一個成員都對一個共享的檔案系統（例如 NFS）擁有訪問權，或者比較少見的多人共用同一臺電腦的情況。後面一種情況並不安全，因為所有程式碼倉庫例項都儲存在同一臺電腦裡，增加了災難性資料損失 的可能性。

如果你使用一個共享的檔案系統，就可以在一個本地檔案系統中克隆倉庫，推送和獲取。克隆的時候只需要將遠端倉庫的路徑作為

$ git clone /opt/git/project.git

或者這樣：

$ git clone file:///opt/git/project.git

如果在 URL 開頭明確使用 file:// ，那麼 Git 會以一種略微不同的方式執行。如果你只給出路徑，Git 會嘗試使用硬連結或直接複製它所需要的檔案。如果使用了file:// ，Git 會呼叫它平時通過網路來傳輸資料的工序，而這種方式的效率相對較低。使用 file:// 字首的主要原因是當你需要一個不包含無關引用或物件的乾淨倉庫副本的時候 — 一般指從其他版本控制系統匯入的，或類似情形（參見第 9 章的維護任務）。我們這裡僅僅使用普通路徑，這樣更快。

要新增一個本地倉庫作為現有 Git 專案的遠端倉庫，可以這樣做：

$ git remote add local_proj /opt/git/project.git

然後就可以像在網路上一樣向這個遠端倉庫推送和獲取資料了。

優點

基於檔案倉庫的優點在於它的簡單，同時保留了現存檔案的許可權和網路訪問許可權。如果你的團隊已經有一個全體共享的檔案系統，建立倉庫就十分容易了。你 只需把一份裸倉庫的副本放在大家都能訪問的地方，然後像對其他共享目錄一樣設定讀寫許可權就可以了。我們將在下一節“在伺服器上部署 Git ”中討論如何匯出一個裸倉庫的副本。

這也是從別人工作目錄中獲取工作成果的快捷方法。假如你和你的同事在一個專案中合作，他們想讓你檢出一些東西的時候，執行類似

缺點

這種方法的缺點是，與基本的網路連線訪問相比，難以控制從不同位置來的訪問許可權。如果你想從家裡的膝上型電腦上推送，就要先掛載遠端硬碟，這和基於網路連線的訪問相比更加困難和緩慢。

另一個很重要的問題是該方法不一定就是最快的，尤其是對於共享掛載的檔案系統。本地倉庫只有在你對資料訪問速度快的時候才快。在同一個伺服器上，如果二者同時允許 Git 訪問本地硬碟，通過 NFS 訪問倉庫通常會比 SSH 慢。

SSH 協議

Git 使用的傳輸協議中最常見的可能就是 SSH 了。這是因為大多數環境已經支援通過 SSH 對伺服器的訪問 — 即便還沒有，架設起來也很容易。SSH 也是唯一一個同時支援讀寫操作的網路協議。另外兩個網路協議（HTTP 和 Git）通常都是隻讀的，所以雖然二者對大多數人都可用，但執行寫操作時還是需要 SSH。SSH 同時也是一個驗證授權的網路協議；而因為其普遍性，一般架設和使用都很容易。

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

$ git clone ssh://[email protected]:project.git

或者不指明某個協議 — 這時 Git 會預設使用 SSH ：

$ git clone [email protected]:project.git

如果不指明使用者，Git 會預設使用當前登入的使用者名稱連線伺服器。

優點

使用 SSH 的好處有很多。首先，如果你想擁有對網路倉庫的寫許可權，基本上不可能不使用 SSH。其次，SSH 架設相對比較簡單 — SSH 守護程序很常見，很多網路管理員都有一些使用經驗，而且很多作業系統都自帶了它或者相關的管理工具。再次，通過 SSH 進行訪問是安全的 — 所有資料傳輸都是加密和授權的。最後，和 Git 及本地協議一樣，SSH 也很高效，會在傳輸之前儘可能壓縮資料。

缺點

SSH 的限制在於你不能通過它實現倉庫的匿名訪問。即使僅為讀取資料，人們也必須在能通過 SSH 訪問主機的前提下才能訪問倉庫，這使得 SSH 不利於開源的專案。如果你僅僅在公司網路裡使用，SSH 可能是你唯一需要使用的協議。如果想允許對專案的匿名只讀訪問，那麼除了為自己推送而架設 SSH 協議之外，還需要支援其他協議以便他人訪問讀取。

Git 協議

接下來是 Git 協議。這是一個包含在 Git 軟體包中的特殊守護程序； 它會監聽一個提供類似於 SSH 服務的特定埠（9418），而無需任何授權。打算支援 Git 協議的倉庫，需要先建立git-export-daemon-ok 檔案 — 它是協議程序提供倉庫服務的必要條件 — 但除此之外該服務沒有什麼安全措施。要麼所有人都能克隆 Git 倉庫，要麼誰也不能。這也意味著該協議通常不能用來進行推送。你可以允許推送操作；然而由於沒有授權機制，一旦允許該操作，網路上任何一個知道專案 URL 的人將都有推送許可權。不用說，這是十分罕見的情況。

優點

Git 協議是現存最快的傳輸協議。如果你在提供一個有很大訪問量的公共專案，或者一個不需要對讀操作進行授權的龐大專案，架設一個 Git 守護程序來供應倉庫是個不錯的選擇。它使用與 SSH 協議相同的資料傳輸機制，但省去了加密和授權的開銷。

缺點

Git 協議消極的一面是缺少授權機制。用 Git 協議作為訪問專案的唯一方法通常是不可取的。一般的做法是，同時提供 SSH 介面，讓幾個開發者擁有推送（寫）許可權，其他人通過git:// 擁有隻讀許可權。Git 協議可能也是最難架設的協議。它要求有單獨的守護程序，需要定製 — 我們將在本章的 “Gitosis” 一節詳細介紹它的架設 — 需要設定xinetd 或類似的程式，而這些工作就沒那麼輕鬆了。該協議還要求防火牆開放 9418 埠，而企業級防火牆一般不允許對這個非標準埠的訪問。大型企業級防火牆通常會封鎖這個少見的埠。

HTTP/S 協議

最後還有 HTTP 協議。HTTP 或 HTTPS 協議的優美之處在於架設的簡便性。基本上，只需要把 Git 的裸倉庫檔案放在 HTTP 的根目錄下，配置一個特定的post-update 掛鉤（hook）就可以搞定（Git 掛鉤的細節見第 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 向倉庫推送內容時執行；之後，其他人就可以用下面的命令來克隆倉庫：

$ git clone http://example.com/gitproject.git

在本例中，我們使用了 Apache 設定中常用的 /var/www/htdocs 路徑，不過你可以使用任何靜態 web 服務 — 把裸倉庫放在它的目錄裡就行。 Git 的資料是以最基本的靜態檔案的形式提供的（關於如何提供檔案的詳情見第 9 章）。

通過 HTTP 進行推送操作也是可能的，不過這種做法不太常見，並且牽扯到複雜的 WebDAV 設定。由於很少用到，本書將略過對該內容的討論。如果對 HTTP 推送協議感興趣，不妨開啟這個地址看一下操作方法：http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt 。通過 HTTP 推送的好處之一是你可以使用任何 WebDAV 伺服器，不需要為 Git 設定特殊環境；所以如果主機提供商支援通過 WebDAV 更新網站內容，你也可以使用這項功能。

優點

使用 HTTP 協議的好處是易於架設。幾條必要的命令就可以讓全世界讀取到倉庫的內容。花費不過幾分鐘。HTTP 協議不會佔用過多伺服器資源。因為它一般只用到靜態的 HTTP 服務提供所有資料，普通的 Apache 伺服器平均每秒能支撐數千個檔案的併發訪問 — 哪怕讓一個小型伺服器超載都很難。

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

HTTP 還有個額外的好處：HTTP 是一個如此常見的協議，以至於企業級防火牆通常都允許其埠的通訊。

缺點

HTTP 協議的消極面在於，相對來說客戶端效率更低。克隆或者下載倉庫內容可能會花費更多時間，而且 HTTP 傳輸的體積和網路開銷比其他任何一個協議都大。因為它沒有按需供應的能力 — 傳輸過程中沒有服務端的動態計算 — 因而 HTTP 協議經常會被稱為_傻瓜（dumb）_協議。更多 HTTP 協議和其他協議效率