到目前為止，你應該已經有辦法使用 Git 來完成日常工作。 然而，為了使用 Git 協作功能，你還需要有遠端的 Git 倉庫。 儘管在技術上你可以從個人倉庫進行推送（push）和拉取（pull）來修改內容，但不鼓勵使用這種方法，因為一不留心就很容易弄混其他人的進度。 此外，你希望你的合作者們即使在你的電腦未聯機時亦能存取倉庫 — 擁有一個更可靠的公用倉庫十分有用。 因此，與他人合作的最佳方法即是建立一個你與合作者們都有權利訪問，且可從那裡推送和拉取資料的共用倉庫。

架設一臺 Git 伺服器並不難。 首先，選擇你希望伺服器使用的通訊協議。 在本章第一節將介紹可用的協議以及各自優缺點。 下面一節將解釋使用那些協議的典型設定及如何在你的伺服器上執行。 最後，如果你不介意託管你的程式碼在其他人的伺服器，且不想經歷設定與維護自己伺服器的麻煩，可以試試我們介紹的幾個倉庫託管服務。

如果你對架設自己的伺服器沒興趣，可以跳到本章最後一節去看看如何申請一個程式碼託管服務的帳戶然後繼續下一章，我們會在那裡討論分散式原始碼控制環境的林林總總。

一個遠端倉庫通常只是一個裸倉庫（bare repository）— 即一個沒有當前工作目錄的倉庫。 因為該倉庫僅僅作為合作媒介，不需要從磁碟檢查快照；存放的只有 Git 的資料。 簡單的說，裸倉庫就是你工程目錄內的 .git 子目錄內容，不包含其他資料。

協議

Git 可以使用四種主要的協議來傳輸資料：本地協議（Local），HTTP 協議，SSH（Secure Shell）協議及 Git 協議。 在此，我們將會討論那些協議及哪些情形應該使用（或避免使用）他們。

本地協議

最基本的就是 本地協議（Local protocol） ，其中的遠端版本庫就是硬碟內的另一個目錄。 這常見於團隊每一個成員都對一個共享的檔案系統（例如一個掛載的 NFS）擁有訪問權，或者比較少見的多人共用同一臺電腦的情況。 後者並不理想，因為你的所有程式碼版本庫如果長存於同一臺電腦，更可能發生災難性的損失。

如果你使用共享檔案系統，就可以從本地版本庫克隆（clone）、推送（push）以及拉取（pull）。 像這樣去克隆一個版本庫或者增加一個遠端到現有的專案中，使用版本庫路徑作為 URL。 例如，克隆一個本地版本庫，可以執行如下的命令：

$ git clone /opt/git/project.git
 

或你可以執行這個命令：

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

如果在 URL 開頭明確的指定 file://，那麼 Git 的行為會略有不同。 如果僅是指定路徑，Git 會嘗試使用硬連結（hard link）或直接複製所需要的檔案。 如果指定 file://，Git 會觸發平時用於網路傳輸資料的程序，那通常是傳輸效率較低的方法。 指定 file:// 的主要目的是取得一個沒有外部參考（extraneous references）或物件（object）的乾淨版本庫副本– 通常是在從其他版本控制系統匯入後或一些類似情況（參見 Git 內部原理 for maintenance tasks）需要這麼做。 在此我們將使用普通路徑，因為這樣通常更快。

要增加一個本地版本庫到現有的 Git 專案，可以執行如下的命令：

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

然後，就可以像在網路上一樣從遠端版本庫推送和拉取更新了。

優點
基於檔案系統的版本庫的優點是簡單，並且直接使用了現有的檔案許可權和網路訪問許可權。 如果你的團隊已經有共享檔案系統，建立版本庫會十分容易。 只需要像設定其他共享目錄一樣，把一個裸版本庫的副本放到大家都可以訪問的路徑，並設定好讀/寫的許可權，就可以了， 我們會在 在伺服器上搭建 Git 討論如何匯出一個裸版本庫。

這也是快速從別人的工作目錄中拉取更新的方法。 如果你和別人一起合作一個專案，他想讓你從版本庫中拉取更新時，執行類似 git pull /home/john/project 的命令比推送到服務再取回簡單多了。

缺點
這種方法的缺點是，通常共享檔案系統比較難配置，並且比起基本的網路連線訪問，這不方便從多個位置訪問。 如果你想從家裡推送內容，必須先掛載一個遠端磁碟，相比網路連線的訪問方式，配置不方便，速度也慢。

值得一提的是，如果你使用的是類似於共享掛載的檔案系統時，這個方法不一定是最快的。 訪問本地版本庫的速度與你訪問資料的速度是一樣的。 在同一個伺服器上，如果允許 Git 訪問本地硬碟，一般的通過 NFS 訪問版本庫要比通過 SSH 訪問慢。

最終，這個協議並不保護倉庫避免意外的損壞。 每一個使用者都有“遠端”目錄的完整 shell 許可權，沒有方法可以阻止他們修改或刪除 Git 內部檔案和損壞倉庫。

HTTP 協議

Git 通過 HTTP 通訊有兩種模式。 在 Git 1.6.6 版本之前只有一個方式可用，十分簡單並且通常是隻讀模式的。 Git 1.6.6 版本引入了一種新的、更智慧的協議，讓 Git 可以像通過 SSH 那樣智慧的協商和傳輸資料。 之後幾年，這個新的 HTTP 協議因為其簡單、智慧變的十分流行。 新版本的 HTTP 協議一般被稱為“智慧” HTTP 協議，舊版本的一般被稱為“啞” HTTP 協議。 我們先了解一下新的“智慧” HTTP 協議。

智慧（Smart） HTTP 協議
“智慧” HTTP 協議的執行方式和 SSH 及 Git 協議類似，只是執行在標準的 HTTP/S 埠上並且可以使用各種 HTTP 驗證機制，這意味著使用起來會比 SSH 協議簡單的多，比如可以使用 HTTP 協議的使用者名稱／密碼的基礎授權，免去設定 SSH 公鑰。

智慧 HTTP 協議或許已經是最流行的使用 Git 的方式了，它即支援像 git:// 協議一樣設定匿名服務，也可以像 SSH 協議一樣提供傳輸時的授權和加密。 而且只用一個 URL 就可以都做到，省去了為不同的需求設定不同的 URL。 如果你要推送到一個需要授權的伺服器上（一般來講都需要），伺服器會提示你輸入使用者名稱和密碼。 從伺服器獲取資料時也一樣。

事實上，類似 GitHub 的服務，你在網頁上看到的 URL （比如， https://github.com/schacon/simplegit[])，和你在克隆、推送（如果你有許可權）時使用的是一樣的。

啞（Dumb） HTTP 協議
如果伺服器沒有提供智慧 HTTP 協議的服務，Git 客戶端會嘗試使用更簡單的“啞” HTTP 協議。 啞 HTTP 協議裡 web 伺服器僅把裸版本庫當作普通檔案來對待，提供檔案服務。 啞 HTTP 協議的優美之處在於設定起來簡單。 基本上，只需要把一個裸版本庫放在 HTTP 根目錄，設定一個叫做 post-update 的掛鉤就可以了（見 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 https://example.com/gitproject.git

這裡我們用了 Apache 裡設定了常用的路徑 /var/www/htdocs，不過你可以使用任何靜態 web 伺服器 —— 只需要把裸版本庫放到正確的目錄下就可以。 Git 的資料是以基本的靜態檔案形式提供的（詳情見 Git 內部原理）。

通常的，會在可以提供讀／寫的智慧 HTTP 服務和簡單的只讀的啞 HTTP 服務之間選一個。 極少會將二者混合提供服務。

優點
我們將只關注智慧 HTTP 協議的優點。

不同的訪問方式只需要一個 URL 以及伺服器只在需要授權時提示輸入授權資訊，這兩個簡便性讓終端使用者使用 Git 變得非常簡單。 相比 SSH 協議，可以使用使用者名稱／密碼授權是一個很大的優勢，這樣使用者就不必須在使用 Git 之前先在本地生成 SSH 金鑰對再把公鑰上傳到伺服器。 對非資深的使用者，或者系統上缺少 SSH 相關程式的使用者，HTTP 協議的可用性是主要的優勢。 與 SSH 協議類似，HTTP 協議也非常快和高效。

你也可以在 HTTPS 協議上提供只讀版本庫的服務，如此你在傳輸資料的時候就可以加密資料；或者，你甚至可以讓客戶端使用指定的 SSL 證書。

另一個好處是 HTTP/S 協議被廣泛使用，一般的企業防火牆都會允許這些埠的資料通過。

缺點
在一些伺服器上，架設 HTTP/S 協議的服務端會比 SSH 協議的棘手一些。 除了這一點，用其他協議提供 Git 服務與 “智慧” HTTP 協議相比就幾乎沒有優勢了。

如果你在 HTTP 上使用需授權的推送，管理憑證會比使用 SSH 金鑰認證麻煩一些。 然而，你可以選擇使用憑證儲存工具，比如 OSX 的 Keychain 或者 Windows 的憑證管理器。 參考 憑證儲存 如何安全地儲存 HTTP 密碼。

SSH 協議

架設 Git 伺服器時常用 SSH 協議作為傳輸協議。 因為大多數環境下已經支援通過 SSH 訪問 —— 即時沒有也比較很容易架設。 SSH 協議也是一個驗證授權的網路協議；並且，因為其普遍性，架設和使用都很容易。

通過 SSH 協議克隆版本庫，你可以指定一個 ssh:// 的 URL：

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

或者使用一個簡短的 scp 式的寫法：

$ git clone [email protected]:project.git

你也可以不指定使用者，Git 會使用當前登入的使用者名稱。

優勢
用 SSH 協議的優勢有很多。 首先，SSH 架設相對簡單 —— SSH 守護程序很常見，多數管理員都有使用經驗，並且多數作業系統都包含了它及相關的管理工具。 其次，通過 SSH 訪問是安全的 —— 所有傳輸資料都要經過授權和加密。 最後，與 HTTP/S 協議、Git 協議及本地協議一樣，SSH 協議很高效，在傳輸前也會盡量壓縮資料。

缺點
SSH 協議的缺點在於你不能通過他實現匿名訪問。 即便只要讀取資料，使用者也要有通過 SSH 訪問你的主機的許可權，這使得 SSH 協議不利於開源的專案。 如果你只在公司網路使用，SSH 協議可能是你唯一要用到的協議。 如果你要同時提供匿名只讀訪問和 SSH 協議，那麼你除了為自己推送架設 SSH 服務以外，還得架設一個可以讓其他人訪問的服務。

Git 協議

接下來是 Git 協議。 這是包含在 Git 裡的一個特殊的守護程序；它監聽在一個特定的埠（9418），類似於 SSH 服務，但是訪問無需任何授權。 要讓版本庫支援 Git 協議，需要先建立一個 git-daemon-export-ok 檔案 —— 它是 Git 協議守護程序為這個版本庫提供服務的必要條件 —— 但是除此之外沒有任何安全措施。 要麼誰都可以克隆這個版本庫，要麼誰也不能。 這意味著，通常不能通過 Git 協議推送。 由於沒有授權機制，一旦你開放推送操作，意味著網路上知道這個專案 URL 的人都可以向專案推送資料。 不用說，極少會有人這麼做。

優點
目前，Git 協議是 Git 使用的網路傳輸協議裡最快的。 如果你的專案有很大的訪問量，或者你的專案很龐大並且不需要為寫進行使用者授權，架設 Git 守護程序來提供服務是不錯的選擇。 它使用與 SSH 相同的資料傳輸機制，但是省去了加密和授權的開銷。

缺點
Git 協議缺點是缺乏授權機制。 把 Git 協議作為訪問專案版本庫的唯一手段是不可取的。 一般的做法裡，會同時提供 SSH 或者 HTTPS 協議的訪問服務，只讓少數幾個開發者有推送（寫）許可權，其他人通過 git:// 訪問只有讀許可權。 Git 協議也許也是最難架設的。 它要求有自己的守護程序，這就要配置 xinetd 或者其他的程式，這些工作並不簡單。 它還要求防火牆開放 9418 埠，但是企業防火牆一般不會開放這個非標準埠。 而大型的企業防火牆通常會封鎖這個埠。