Git詳解之四 服務器上的Git（第一部分）

       到目前爲止，你應該已經學會了使用 Git 來完成平常工做。然而，若是想與他人合做，還須要一個遠程的 Git 倉庫。儘管技術上能夠從我的的倉庫裏推送和拉取修改內容，但咱們不鼓勵這樣作，由於一不留心就很容易弄混其餘人的進度。另外，你也必定但願合做者們即便在 本身不開機的時候也能從倉庫獲取數據 — 擁有一個更穩定的公共倉庫十分有用。所以，更好的合做方式是創建一個你們均可以訪問的共享倉庫，從那裏推送和拉取數據。咱們將把這個倉庫稱爲 「Git 服務器」；代理一個 Git 倉庫只須要花費不多的資源，幾乎從不須要整個服務器來支持它的運行。

架設一臺 Git 服務器並不難。第一步是選擇與服務器通信的協議。本章第一節將介紹可用的協議以及各自優缺點。下面一節將介紹一些針對各個協議典型的設置以及如何在服務器 上實施。最後，若是你不介意在他人服務器上保存你的代碼，又想免去本身架設和維護服務器的麻煩，倒能夠試試咱們介紹的幾個倉庫託管服務。

若是你對架設本身的服務器沒興趣，能夠跳到本章最後一節去看看如何申請一個代碼託管服務的帳戶而後繼續下一章，咱們會在那裏討論分佈式源碼控制環境的林林總總。

遠程倉庫一般只是一個_裸倉庫（bare repository）_ — 即一個沒有當前工做目錄的倉庫。由於該倉庫只是一個合做媒介，因此不須要從硬盤上取出最新版本的快照；倉庫裏存放的僅僅是 Git 的數據。簡單地說，裸倉庫就是你工做目錄中.git 子目錄內的內容。

4.1  協議

       Git 可使用四種主要的協議來傳輸數據：本地傳輸，SSH 協議，Git 協議和 HTTP 協議。下面分別介紹一下哪些情形應該使用（或避免使用）這些協議。值得注意的是，除了 HTTP 協議外，其餘全部協議都要求在服務器端安裝並運行 Git。

本地協議

       最基本的就是_本地協議（Local protocol）_，所謂的遠程倉庫在該協議中的表示，就是硬盤上的另外一個目錄。這常見於團隊每個成員都對一個共享的文件系統（例如 NFS）擁有訪問權，或者比較少見的多人共用同一臺電腦的狀況。後面一種狀況並不安全，由於全部代碼倉庫實例都儲存在同一臺電腦裏，增長了災難性數據損失 的可能性。若是你使用一個共享的文件系統，就能夠在一個本地文件系統中克隆倉庫，推送和獲取。克隆的時候只須要將遠程倉庫的路徑做爲 URL 使用，好比下面這樣：

$ 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 pull /home/john/project 一般會比他們推送到服務器，而你再從服務器獲取簡單得多。

缺點

       這種方法的缺點是，與基本的網絡鏈接訪問相比，難以控制從不一樣位置來的訪問權限。若是你想從家裏的筆記本電腦上推送，就要先掛載遠程硬盤，這和基於網絡鏈接的訪問相比更加困難和緩慢。

另外一個很重要的問題是該方法不必定就是最快的，尤爲是對於共享掛載的文件系統。本地倉庫只有在你對數據訪問速度快的時候才快。在同一個服務器上，若是兩者同時容許 Git 訪問本地硬盤，經過 NFS 訪問倉庫一般會比 SSH 慢。

SSH 協議

        Git 使用的傳輸協議中最多見的可能就是 SSH 了。這是由於大多數環境已經支持經過 SSH 對服務器的訪問 — 即使尚未，架設起來也很容易。SSH 也是惟一一個同時支持讀寫操做的網絡協議。另外兩個網絡協議（HTTP 和 Git）一般都是隻讀的，因此雖然兩者對大多數人均可用，但執行寫操做時仍是須要 SSH。SSH 同時也是一個驗證受權的網絡協議；而由於其廣泛性，通常架設和使用都很容易。

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

$ git clone ssh://user@server:project.git

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

$ git clone user@server: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.sampl

這樣就能夠了。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 協議和其餘協議效率上的差別見第 9 。

4.2  在服務器上部署 Git

       開始架設 Git 服務器前，須要先把現有倉庫導出爲裸倉庫 — 即一個不包含當前工做目錄的倉庫。作法直截了當，克隆時用--bare 選項便可。裸倉庫的目錄名通常以.git 結尾，像這樣：

$ git clone --bare my_project my_project.git 
Initialized empty Git repository in /opt/projects/my_project.git/

      該命令的輸出或許會讓人有些不解。其實 clone 操做基本上至關於 git init 加 git fetch，因此這裏出現的實際上是git init 的輸出，先由它創建一個空目錄，而以後傳輸數據對象的操做並沒有任何輸出，只是悄悄在幕後執行。如今my_project.git 目錄中已經有了一份 Git 目錄數據的副本。

總體上的效果大體至關於：

$ cp -Rf my_project/.git my_project.git

     但在配置文件中有若干小改動，不過對用戶來說，使用方式都同樣，不會有什麼影響。它僅取出 Git 倉庫的必要原始數據，存放在該目錄中，而不會另外建立工做目錄。

把裸倉庫移到服務器上

     有了裸倉庫的副本後，剩下的就是把它放到服務器上並設定相關協議。假設一個域名爲 git.example.com 的服務器已經架設好，並能夠經過 SSH 訪問，咱們打算把全部 Git 倉庫儲存在/opt/git 目錄下。只要把裸倉庫複製過去：

$ scp -r my_project.git user@git.example.com:/opt/git

     如今，全部對該服務器有 SSH 訪問權限，並可讀取 /opt/git 目錄的用戶均可以用下面的命令克隆該項目：

$ git clone user@git.example.com:/opt/git/my_project.git

      若是某個 SSH 用戶對 /opt/git/my_project.git 目錄有寫權限，那他就有推送權限。若是到該項目目錄中運行git init 命令，並加上 --shared 選項，那麼 Git 會自動修改該倉庫目錄的組權限爲可寫（譯註：實際上 --shared能夠指定其餘行爲，只是默認爲將組權限改成可寫並執行 g+sx，因此最後會獲得 rws。）。

$ ssh user@git.example.com 
$ cd /opt/git/my_project.git 
$ git init --bare --shared

      因而可知，根據現有的 Git 倉庫建立一個裸倉庫，而後把它放上你和同事都有 SSH 訪問權的服務器是多麼容易。如今已經能夠開始在同一項目上密切合做了。

值得注意的是，這的的確確是架設一個少數人具備鏈接權的 Git 服務的所有 — 只要在服務器上加入能夠用 SSH 登陸的賬號，而後把裸倉庫放在你們都有讀寫權限的地方。一切都準備停當，無需更多。

       下面的幾節中，你會了解如何擴展到更復雜的設定。這些內容包含如何避免爲每個用戶創建一個帳戶，給倉庫添加公共讀取權限，架設網頁界面，使用 Gitosis 工具等等。然而，只是和幾我的在一個不公開的項目上合做的話，僅僅是一個 SSH 服務器和裸倉庫就足夠了，記住這點就能夠了。

小型安裝

       若是設備較少或者你只想在小型開發團隊裏嘗試 Git ，那麼一切都很簡單。架設 Git 服務最複雜的地方在於帳戶管理。若是須要倉庫對特定的用戶可讀，而給另外一部分用戶讀寫權限，那麼訪問和許可的安排就比較困難。

SSH 鏈接

      若是已經有了一個全部開發成員均可以用 SSH 訪問的服務器，架設第一個服務器將變得異常簡單，幾乎什麼都不用作（正如上節中介紹的那樣）。若是須要對倉庫進行更復雜的訪問控制，只要使用服務器操做系統的本地文件訪問許可機制就好了。

      若是須要團隊裏的每一個人都對倉庫有寫權限，又不能給每一個人在服務器上創建帳戶，那麼提供 SSH 鏈接就是惟一的選擇了。咱們假設用來共享倉庫的服務器已經安裝了 SSH 服務，並且你經過它訪問服務器。

       有好幾個辦法可讓團隊的每一個人都有訪問權.

第一個辦法是給每一個人創建一個帳戶，直截了當但略過繁瑣。反覆運行adduser 並給全部人設定臨時密碼可不是好玩的。

第二個辦法是在主機上創建一個 git 帳戶，讓每一個須要寫權限的人發送一個 SSH 公鑰，而後將其加入 git 帳戶的~/.ssh/authorized_keys 文件。這樣一來，全部人都將經過 git 帳戶訪問主機。這絲絕不會影響提交的數據 — 訪問主機用的身份不會影響提交對象的提交者信息。

另外一個辦法是讓 SSH 服務器經過某個 LDAP 服務，或者其餘已經設定好的集中受權機制，來進行受權。只要每一個人都能得到主機的 shell 訪問權，任何可用的 SSH 受權機制都能達到相同效果。

4.3  生成 SSH 公鑰

       大多數 Git 服務器都會選擇使用 SSH 公鑰來進行受權。系統中的每一個用戶都必須提供一個公鑰用於受權，沒有的話就要生成一個。生成公鑰的過程在全部操做系統上都差很少。首先先確認一下是否已經有一個公鑰了。SSH 公鑰默認儲存在帳戶的主目錄下的~/.ssh 目錄。進去看看：

$ cd ~/.ssh 
$ ls authorized_keys2 id_dsa known_hosts config id_dsa.pub

關鍵是看有沒有用 something 和 something.pub 來命名的一對文件，這個 something 一般就是 id_dsa 或id_rsa。有 .pub 後綴的文件就是公鑰，另外一個文件則是密鑰。假如沒有這些文件，或者乾脆連.ssh 目錄都沒有，能夠用 ssh-keygen 來建立。該程序在 Linux/Mac 系統上由 SSH 包提供，而在 Windows 上則包含在 MSysGit 包裏：

$ ssh-keygen 
Generating public/private rsa key pair. Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): Enter p

它先要求你確認保存公鑰的位置（.ssh/id_rsa），而後它會讓你重複一個密碼兩次，若是不想在使用公鑰的時候輸入密碼，能夠留空。

如今，全部作過這一步的用戶都得把它們的公鑰給你或者 Git 服務器的管理員（假設 SSH 服務被設定爲使用公鑰機制）。他們只須要複製 .pub 文件的內容而後發郵件給管理員。公鑰的樣子大體以下：

$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18J...

4.4  架設服務器

       如今咱們過一邊服務器端架設 SSH 訪問的流程。本例將使用 authorized_keys 方法來給用戶受權。咱們還將假定使用相似 Ubuntu 這樣的標準 Linux 發行版。首先，建立一個名爲 ‘git’ 的用戶，併爲其建立一個.ssh 目錄。

$ sudo adduser git 
$ su git 
$ cd 
$ mkdir .ssh

       接下來，把開發者的 SSH 公鑰添加到這個用戶的 authorized_keys 文件中。假設你經過電郵收到了幾個公鑰並存到了臨時文件裏。重複一下，公鑰大體看起來是這個樣子：

$ cat /tmp/id_rsa.john.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L ojG6rs6hPB09j9R/T17/x4lhJA

只要把它們逐個追加到 authorized_keys 文件尾部便可：

$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id_rsa...

       如今能夠用 --bare 選項運行 git init 來創建一個裸倉庫，這會初始化一個不包含工做目錄的倉庫。

$ cd /opt/git $ mkdir project.git 
$ cd project.git 
$ git --bare init

       這時，Join，Josie 或者 Jessica 就能夠把它加爲遠程倉庫，推送一個分支，從而把第一個版本的項目文件上傳到倉庫裏了。值得注意的是，每次添加一個新項目都須要經過 shell 登入主機並建立一個裸倉庫目錄。咱們不妨以gitserver 做爲git 用戶及項目倉庫所在的主機名。若是在網絡內部運行該主機，並在 DNS 中設定 gitserver 指向該主機，那麼如下這些命令都是可用的：

# 在 John 的電腦上 
$ cd myproject $ git init 
$ git add . 
$ git commit -m 'initial commit' 
$ git remote add origin git@gitserver/path/*.git
$ git push

這樣，其餘人的克隆和推送也同樣變得很簡單：

$ git clone git@gitserver:/opt/git/project.git 
$ vim README 
$ git commit -am 'fix for the README file' 
$ git push origin master

用這個方法能夠很快捷地爲少數幾個開發者架設一個可讀寫的 Git 服務。

       做爲一個額外的防範措施，你能夠用 Git 自帶的 git-shell 工具限制 git 用戶的活動範圍。只要把它設爲git 用戶登入的 shell，那麼該用戶就沒法使用普通的 bash 或者 csh 什麼的 shell 程序。編輯 /etc/passwd 文件：

$ sudo vim /etc/passwd

在文件末尾，你應該能找到相似這樣的行：

git:x:1000:1000::/home/git:/bin/sh

把 bin/sh 改成 /usr/bin/git-shell （或者用 which git-shell 查看它的實際安裝路徑）。該行修改後的樣子以下：

git:x:1000:1000::/home/git:/usr/bin/git-shell

如今 git 用戶只能用 SSH 鏈接來推送和獲取 Git 倉庫，而不能直接使用主機 shell。嘗試普通 SSH 登陸的話，會看到下面這樣的拒絕信息：

$ ssh git@gitserver 
fatal: What do you think I am? A shell? Connection to gitserver closed.

4.5  公共訪問

      匿名的讀取權限該怎麼實現呢？也許除了內部私有的項目以外，你還須要託管一些開源項目。或者由於要用一些自動化的服務器來進行編譯，或者有一些常常變化的服務器羣組，而又不想成天生成新的 SSH 密鑰 — 總之，你須要簡單的匿名讀取權限。

     或許對小型的配置來講最簡單的辦法就是運行一個靜態 web 服務，把它的根目錄設定爲 Git 倉庫所在的位置，而後開啓本章第一節提到的 post-update 掛鉤。這裏繼續使用以前的例子。假設倉庫處於/opt/git 目錄，主機上運行着 Apache 服務。重申一下，任何 web 服務程序均可以達到相同效果；做爲範例，咱們將用一些基本的 Apache 設定來展現大致須要的步驟。

首先，開啓掛鉤：

$ cd project.git 
$ mv hooks/post-update.sample 
hooks/post-update 
$ chmod a+x hooks/post-update

      若是用的是 Git 1.6 以前的版本，則能夠省略 mv 命令 — Git 是從較晚的版本纔開始在掛鉤實例的結尾添加 .sample 後綴名的。

post-update 掛鉤是作什麼的呢？其內容大體以下：

$ cat .git/hooks/post-update 
#!/bin/sh exec git-update-server-info

       意思是當經過 SSH 向服務器推送時，Git 將運行這個 git-update-server-info 命令來更新匿名 HTTP 訪問獲取數據時所須要的文件。

      接下來，在 Apache 配置文件中添加一個 VirtualHost 條目，把文檔根目錄設爲 Git 項目所在的根目錄。這裏咱們假定 DNS 服務已經配置好，會把對.gitserver 的請求發送到這臺主機：

ServerName git.gitserver DocumentRoot /opt/git Order allow, deny allow from all

另外，須要把 /opt/git 目錄的 Unix 用戶組設定爲 www-data ，這樣 web 服務才能夠讀取倉庫內容，由於運行 CGI 腳本的 Apache 實例進程默認就是以該用戶的身份起來的：

$ chgrp -R www-data /opt/git

重啓 Apache 以後，就能夠經過項目的 URL 來克隆該目錄下的倉庫了。

$ git clone http://git.gitserver/project.git

這一招可讓你在幾分鐘內爲至關數量的用戶架設好基於 HTTP 的讀取權限。另外一個提供非受權訪問的簡單方法是開啓一個 Git 守護進程，不過這將要求該進程做爲後臺進程常駐 — 接下來的這一節就要討論這方面的細節。

4.6  GitWeb

       如今咱們的項目已經有了可讀可寫和只讀的鏈接方式，不過若是能有一個簡單的 web 界面訪問就更好了。Git 自帶一個叫作 GitWeb 的 CGI 腳本，運行效果能夠到http://git.kernel.org 這樣的站點體驗下（見圖 4-1）。

    

    若是想看看本身項目的效果，不妨用 Git 自帶的一個命令，可使用似 lighttpd 或 webrick 這樣輕量級的服務器啓動一個臨時進程。若是是在 Linux 主機上，一般都預裝了lighttpd ，能夠到項目目錄中鍵入 git instaweb 來啓動。若是用的是 Mac ，Leopard 預裝了 Ruby，因此webrick 應該是最好的選擇。若是要用 lighttpd 之外的程序來啓動

git instaweb，能夠經過--httpd 選項指定：

$ git instaweb --httpd=webrick 
[2009-02-21 10:02:21] INFO WEBrick 1.3.1 [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03)

      這會在 1234 端口開啓一個 HTTPD 服務，隨之在瀏覽器中顯示該頁，十分簡單。關閉服務時，只需在原來的命令後面加上--stop 選項就能夠了：

$ git instaweb --httpd=webrick --stop

若是須要爲團隊或者某個開源項目長期運行 GitWeb，那麼 CGI 腳本就要由正常的網頁服務來運行。一些 Linux 發行版能夠經過 apt 或yum 安裝一個叫作 gitweb 的軟件包，不妨首先嚐試一下。咱們將快速介紹一下手動安裝 GitWeb 的流程。首先，你須要 Git 的源碼，其中帶有 GitWeb，並能生成定製的 CGI 腳本：

$ git clone git://git.kernel.org/pub/scm/git/git.git 
$ cd git/ 
$ make GITWEB_PROJECTROOT="/opt/git" \ prefix=/usr gitweb/gitw

注意，經過指定 GITWEB_PROJECTROOT 變量告訴編譯命令 Git 倉庫的位置。而後，設置 Apache 以 CGI 方式運行該腳本，添加一個 VirtualHost 配置：

ServerName gitserver DocumentRoot /var/www/gitweb Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch AllowOverride All ord

不難想象，GitWeb 可使用任何兼容 CGI 的網頁服務來運行；若是偏向使用其餘 web 服務器，配置也不會很麻煩。如今，經過 http://gitserver 就能夠在線訪問倉庫了，在http://git.server 上還能夠經過 HTTP 克隆和獲取倉庫的內容。