【轉】Git詳解之四服務器上的Git

時間 2019-11-07

標籤 git 詳解之四服務器欄目 Git 简体版

原文原文鏈接

服務器上的 Git

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

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

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

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

4.1 協議

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

值得注意的是，除了 HTTP 協議外，其餘全部協議都要求在服務器端安裝並運行 Git。shell

本地協議

最基本的就是_本地協議（Local protocol）_，所謂的遠程倉庫在該協議中的表示，就是硬盤上的另外一個目錄。這常見於團隊每個成員都對一個共享的文件系統（例如 NFS）擁有訪問權，或者比較少見的多人共用同一臺電腦的狀況。後面一種狀況並不安全，由於全部代碼倉庫實例都儲存在同一臺電腦裏，增長了災難性數據損失的可能性。express

若是你使用一個共享的文件系統，就能夠在一個本地文件系統中克隆倉庫，推送和獲取。克隆的時候只須要將遠程倉庫的路徑做爲 URL 使用，好比下面這樣：vim

$ 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.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 協議和其餘協議效率上的差別見第 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 passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/schacon/.ssh/id_rsa.
Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
The key fingerprint is:
43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local

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

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

$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== schacon@agadorlaptop.local

關於在多個操做系統上設立相同 SSH 公鑰的教程，能夠查閱 GitHub 上有關 SSH 公鑰的嚮導：http://github.com/guides/providing-your-ssh-key。

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/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair

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

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

如今能夠用 --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:/opt/git/project.git
$ git push origin master

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

$ 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）。

Figure 4-1. 基於網頁的 GitWeb 用戶界面

若是想看看本身項目的效果，不妨用 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) [universal-darwin9.0]

這會在 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/gitweb.cgi
$ sudo cp -Rf gitweb /var/www/

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

ServerName gitserver
    DocumentRoot /var/www/gitweb
             Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
        AllowOverride All
        order allow,deny
        Allow from all
        AddHandler cgi-script cgi
        DirectoryIndex gitweb.cgi

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

4.7 Gitosis

把全部用戶的公鑰保存在 authorized_keys 文件的作法，只能湊和一陣子，當用戶數量達到幾百人的規模時，管理起來就會十分痛苦。每次改刪用戶都必須登陸服務器不去說，這種作法還缺乏必要的權限管理 — 每一個人都對全部項目擁有完整的讀寫權限。

幸虧咱們還能夠選擇應用普遍的 Gitosis 項目。簡單地說，Gitosis 就是一套用來管理 authorized_keys 文件和實現簡單鏈接限制的腳本。有趣的是，用來添加用戶和設定權限的並不是經過網頁程序，而只是管理一個特殊的 Git 倉庫。你只須要在這個特殊倉庫內作好相應的設定，而後推送到服務器上，Gitosis 就會隨之改變運行策略，聽起來就很酷，對吧？

Gitosis 的安裝算不上傻瓜化，但也不算太難。用 Linux 服務器架設起來最簡單 — 如下例子中，咱們使用裝有 Ubuntu 8.10 系統的服務器。

Gitosis 的工做依賴於某些 Python 工具，因此首先要安裝 Python 的 setuptools 包，在 Ubuntu 上稱爲 python-setuptools：

$ apt-get install python-setuptools

接下來，從 Gitosis 項目主頁克隆並安裝：

$ git clone git://eagain.net/gitosis.git
$ cd gitosis
$ sudo python setup.py install

這會安裝幾個供 Gitosis 使用的工具。默認 Gitosis 會把 /home/git 做爲存儲全部 Git 倉庫的根目錄，這沒什麼很差，不過咱們以前已經把項目倉庫都放在/opt/git 裏面了，因此爲方便起見，咱們能夠作一個符號鏈接，直接劃轉過去，而沒必要從新配置：

$ ln -s /opt/git /home/git/repositories

Gitosis 將會幫咱們管理用戶公鑰，因此先把當前控制文件更名備份，以便稍後從新添加，準備好讓 Gitosis 自動管理authorized_keys 文件：

$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak

接下來，若是以前把 git 用戶的登陸 shell 改成 git-shell 命令的話，先恢復 ‘git’ 用戶的登陸 shell。改過以後，你們仍然沒法經過該賬號登陸（譯註：由於authorized_keys 文件已經沒有了。），不過不用擔憂，這會交給 Gitosis 來實現。因此如今先打開 /etc/passwd 文件，把這行：

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

改回:

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

好了，如今能夠初始化 Gitosis 了。你能夠用本身的公鑰執行 gitosis-init 命令，要是公鑰不在服務器上，先臨時複製一份：

$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
Initialized empty Git repository in /opt/git/gitosis-admin.git/
Reinitialized existing Git repository in /opt/git/gitosis-admin.git/

這樣該公鑰的擁有者就能修改用於配置 Gitosis 的那個特殊 Git 倉庫了。接下來，須要手工對該倉庫中的 post-update 腳本加上可執行權限：

$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update

基本上就算是好了。若是設定過程沒出什麼差錯，如今能夠試一下用初始化 Gitosis 的公鑰的擁有者身份 SSH 登陸服務器，應該會看到相似下面這樣：

$ ssh git@gitserver
PTY allocation request failed on channel 0
fatal: unrecognized command 'gitosis-serve schacon@quaternion'
  Connection to gitserver closed.

說明 Gitosis 認出了該用戶的身份，但因爲沒有運行任何 Git 命令，因此它切斷了鏈接。那麼，如今運行一個實際的 Git 命令 — 克隆 Gitosis 的控制倉庫：

# 在你本地計算機上
$ git clone git@gitserver:gitosis-admin.git

這會獲得一個名爲 gitosis-admin 的工做目錄，主要由兩部分組成：

$ cd gitosis-admin
$ find .
./gitosis.conf
./keydir
./keydir/scott.pub

gitosis.conf 文件是用來設置用戶、倉庫和權限的控制文件。keydir 目錄則是保存全部具備訪問權限用戶公鑰的地方— 每人一個。在keydir 裏的文件名（好比上面的 scott.pub）應該跟你的不同 — Gitosis 會自動從使用 gitosis-init 腳本導入的公鑰尾部的描述中獲取該名字。

看一下 gitosis.conf 文件的內容，它應該只包含與剛剛克隆的 gitosis-admin 相關的信息：

$ cat gitosis.conf 
[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = scott

它顯示用戶 scott — 初始化 Gitosis 公鑰的擁有者 — 是惟一能管理 gitosis-admin 項目的人。

如今咱們來添加一個新項目。爲此咱們要創建一個名爲 mobile 的新段落，在其中羅列手機開發團隊的開發者，以及他們擁有寫權限的項目。因爲 ‘scott’ 是系統中的惟一用戶，咱們把他設爲惟一用戶，並容許他讀寫名爲iphone_project 的新項目：

[group mobile]
writable = iphone_project
members = scott

修改完以後，提交 gitosis-admin 裏的改動，並推送到服務器使其生效：

$ git commit -am 'add iphone_project and mobile group'
[master]: created 8962da8: "changed name"
 1 files changed, 4 insertions(+), 0 deletions(-)
$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 272 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@gitserver:/opt/git/gitosis-admin.git
   fb27aec..8962da8  master -> master

在新工程 iphone_project 裏首次推送數據到服務器前，得先設定該服務器地址爲遠程倉庫。但你不用事先到服務器上手工建立該項目的裸倉庫— Gitosis 會在第一次遇到推送時自動建立：

$ git remote add origin git@gitserver:iphone_project.git
$ git push origin master
Initialized empty Git repository in /opt/git/iphone_project.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 230 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@gitserver:iphone_project.git
 * [new branch]      master -> master

請注意，這裏不用指明完整路徑（實際上，若是加上反而沒用），只須要一個冒號加項目名字便可 — Gitosis 會自動幫你映射到實際位置。

要和朋友們在一個項目上協同工做，就得從新添加他們的公鑰。不過此次不用在服務器上一個一個手工添加到~/.ssh/authorized_keys 文件末端，而只需管理keydir 目錄中的公鑰文件。文件的命名將決定在 gitosis.conf 中對用戶的標識。如今咱們爲 John，Josie 和 Jessica 添加公鑰：

$ cp /tmp/id_rsa.john.pub keydir/john.pub
$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
$ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub

而後把他們都加進 ‘mobile’ 團隊，讓他們對 iphone_project 具備讀寫權限：

[group mobile]
writable = iphone_project
members = scott john josie jessica

若是你提交併推送這個修改，四個用戶將同時具備該項目的讀寫權限。

Gitosis 也具備簡單的訪問控制功能。若是想讓 John 只有讀權限，能夠這樣作：

[group mobile]
writable = iphone_project
members = scott josie jessica

[group mobile_ro]
readonly = iphone_project
members = john

如今 John 能夠克隆和獲取更新，但 Gitosis 不會容許他向項目推送任何內容。像這樣的組能夠隨意建立，多少不限，每一個均可以包含若干不一樣的用戶和項目。甚至還能夠指定某個組爲成員之一（在組名前加上@ 前綴），自動繼承該組的成員：

[group mobile_committers]
members = scott josie jessica

[group mobile]
writable  = iphone_project
members   = @mobile_committers

[group mobile_2]
writable  = another_iphone_project
members   = @mobile_committers john

若是遇到意外問題，試試看把 loglevel=DEBUG 加到 [gitosis] 的段落（譯註：把日誌設置爲調試級別，記錄更詳細的運行信息。）。若是一不當心搞錯了配置，失去了推送權限，也能夠手工修改服務器上的/home/git/.gitosis.conf 文件 — Gitosis 實際是從該文件讀取信息的。它在獲得推送數據時，會把新的 gitosis.conf 存到該路徑上。因此若是你手工編輯該文件的話，它會一直保持到下次向 gitosis-admin 推送新版本的配置內容爲止。

4.8 Gitolite

Note: the latest copy of this section of the ProGit book is always available within thegitolite documentation. The author would also like to humbly state that, while this section is accurate, andcan (and often has) been used to install gitolite without reading any other documentation, it is of necessity not complete, and cannot completely replace the enormous amount of documentation that gitolite comes with.

Git has started to become very popular in corporate environments, which tend to have some additional requirements in terms of access control. Gitolite was originally created to help with those requirements, but it turns out that it’s equally useful in the open source world: the Fedora Project controls access to their package management repositories (over 10,000 of them!) using gitolite, and this is probably the largest gitolite installation anywhere too.

Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain 「refs」 (branches or tags) but not others.

Installing

Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind; various Linux flavours, and Solaris 10, have been tested. You do not need root access, assuming git, perl, and an openssh compatible ssh server are already installed. In the examples below, we will use thegitolite account on a host called gitserver.

Gitolite is somewhat unusual as far as 「server」 software goes – access is via ssh, and so every userid on the server is a potential 「gitolite host」. As a result, there is a notion of 「installing」 the software itself, and then 「setting up」 a user as a 「gitolite host」.

Gitolite has 4 methods of installation. People using Fedora or Debian systems can obtain an RPM or a DEB and install that. People with root access can install it manually. In these two methods, any user on the system can then become a 「gitolite host」.

People without root access can install it within their own userids. And finally, gitolite can be installed by running a scripton the workstation, from a bash shell. (Even the bash that comes with msysgit will do, in case you’re wondering.)

We will describe this last method in this article; for the other methods please see the documentation.

You start by obtaining public key based access to your server, so that you can log in from your workstation to the server without getting a password prompt. The following method works on Linux; for other workstation OSs you may have to do this manually. We assume you already had a key pair generated using ssh-keygen.

$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver

This will ask you for the password to the gitolite account, and then set up public key access. This isessential for the install script, so check to make sure you can run a command without getting a password prompt:

$ ssh gitolite@gitserver pwd
/home/gitolite

Next, you clone Gitolite from the project’s main site and run the 「easy install」 script (the third argument is your name as you would like it to appear in the resulting gitolite-admin repository):

$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q gitolite gitserver sitaram

And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository calledgitolite-admin in the home directory of your workstation. You administer your gitolite setup by making changes to this repository and pushing.

That last command does produce a fair amount of output, which might be interesting to read. Also, the first time you run this, a new keypair is created; you will have to choose a passphrase or hit enter for none. Why a second keypair is needed, and how it is used, is explained in the 「ssh troubleshooting」 document that comes with Gitolite. (Hey the documentation has to be good forsomething!)

Repos named gitolite-admin and testing are created on the server by default. If you wish to clone either of these locally (from an account that has SSH console access to the gitolite account viaauthorized_keys), type:

$ git clone gitolite:gitolite-admin
$ git clone gitolite:testing

To clone these same repos from any other account:

$ git clone gitolite@servername:gitolite-admin
$ git clone gitolite@servername:testing

Customising the Install

While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the-q argument, you get a 「verbose」 mode install – detailed information on what the install is doing at each step. The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an 「rc」 file that the server uses. This 「rc」 file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue. This file also contains various settings that you can change to enable or disable some of gitolite’s advanced features.

Config File and Access Control Rules

Once the install is done, you switch to the gitolite-admin repository (placed in your HOME directory) and poke around to see what you got:

$ cd ~/gitolite-admin/
$ ls
conf/  keydir/
$ find conf keydir -type f
conf/gitolite.conf
keydir/sitaram.pub
$ cat conf/gitolite.conf
#gitolite conf
# please see conf/example.conf for details on syntax and features

repo gitolite-admin
    RW+                 = sitaram

repo testing
    RW+                 = @all

Notice that 「sitaram」 (the last argument in the gl-easy-install command you gave earlier) has read-write permissions on thegitolite-admin repository as well as a public key file of the same name.

The config file syntax for gitolite is liberally documented in conf/example.conf, so we’ll only mention some highlights here.

You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when youuse the 「macro」.

@oss_repos      = linux perl rakudo git gitolite
@secret_repos   = fenestra pear

@admins          = scott     # Adams, not Chacon, sorry :)
@interns        = ashok     # get the spelling right, Scott!
@engineers      = sitaram dilbert wally alice
@staff           = @admins  @engineers @interns

You can control permissions at the 「ref」 level. In the following example, interns can only push the 「int」 branch. Engineers can push any branch whose name starts with 「eng-「, and tags that start with 「rc」 followed by a digit. And the admins can do anything (including rewind) to any ref.

repo @oss_repos
    RW  int$                = @interns
    RW  eng-                = @engineers
    RW  refs/tags/rc[0-9]   = @engineers
    RW+                     = @admins

The expression after the RW or RW+ is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a 「refex」! Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with perl regexes.

Also, as you probably guessed, Gitolite prefixes refs/heads/ as a syntactic convenience if the refex does not begin withrefs/.

An important feature of the config file’s syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for alloss_repos shown above, then add specific rules for specific cases later on, like so:

repo gitolite
    RW+                     = sitaram

That rule will just get added to the ruleset for the gitolite repository.

At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.

There are two levels of access control in gitolite. The first is at the repository level; if you have read (or write) access toany ref in the repository, then you have read (or write) access to the repository.

The second level, applicable only to 「write」 access, is by branch or tag within a repository. The username, the access being attempted (W or+), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied.

Advanced Access Control with 「deny」 rules

So far, we’ve only seen permissions to be one or R, RW, orRW+. However, gitolite allows another permission: -, standing for 「deny」. This gives you a lot more power, at the expense of some complexity, because now fallthrough is not theonly way for access to be denied, so the order of the rules now matters!

Let us say, in the situation above, we want engineers to be able to rewind any branchexcept master and integ. Here’s how to do that:

RW  master integ    = @engineers
    -   master integ    = @engineers
    RW+                 = @engineers

Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it.

Restricting pushes by files changed

In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done just right. You can tell gitolite:

repo foo
    RW                  =   @junior_devs @senior_devs

    RW  NAME/           =   @senior_devs
    -   NAME/Makefile   =   @junior_devs
    RW  NAME/           =   @junior_devs

This powerful feature is documented in conf/example.conf.

Personal Branches

Gitolite also has a feature called 「personal branches」 (or rather, 「personal branch namespace」) that can be very useful in a corporate environment.

A lot of code exchange in the git world happens by 「please pull」 requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.

This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.

Gitolite lets you define a 「personal」 or 「scratch」 namespace prefix for each developer (for example,refs/personal//*); see the 「personal branches」 section in doc/3-faq-tips-etc.mkd for details.

「Wildcard」 repositories

Gitolite allows you to specify repositories with wildcards (actually perl regexes), like, for exampleassignments/s[0-9][0-9]/a[0-9][0-9], to pick a random example. This is avery powerful feature, which has to be enabled by setting$GL_WILDREPOS = 1; in the rc file. It allows you to assign a new permission mode (」C」) which allows users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out R and RW permissions to other users to collaborate, etc. This feature is documented indoc/4-wildcard-repositories.mkd.

Other Features

We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the 「faqs, tips, etc」 and other documents.

Logging: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (RW+) and some kid blew away 「master」, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.

Git outside normal PATH: One extremely useful convenience feature in gitolite is support for git installed outside the normal$PATH (this is more common than you think; some corporate environments or even some hosting providers refuse to install things system-wide and you end up putting them in your own directories). Normally, you are forced to make theclient-side git aware of this non-standard location of the git binaries in some way. With gitolite, just choose a verbose install and set$GIT_PATH in the 「rc」 files. No client-side changes are required after that :-)

Access rights reporting: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example:

hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
    the gitolite config gives you the following access:
         R     anu-wsd
         R     entrans
         R  W  git-notes
         R  W  gitolite
         R  W  gitolite-admin
         R     indic_web_input
         R     shreelipi_converter

Delegation: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. This feature has its own documentation file in the doc/ directory.

Gitweb support: Gitolite supports gitweb in several ways. You can specify which repos are visible via gitweb. You can set the 「owner」 and 「description」 for gitweb from the gitolite config file. Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the 「compiled」 config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite.

Mirroring: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.

4.9 Git 守護進程

對於提供公共的，非受權的只讀訪問，咱們能夠拋棄 HTTP 協議，改用 Git 本身的協議，這主要是出於性能和速度的考慮。Git 協議遠比 HTTP 協議高效，於是訪問速度也快，因此它能節省不少用戶的時間。

重申一下，這一點只適用於非受權的只讀訪問。若是建在防火牆以外的服務器上，那麼它所提供的服務應該只是那些公開的只讀項目。若是是在防火牆以內的服務器上，可用於支撐大量參與人員或自動系統（用於持續集成或編譯的主機）只讀訪問的項目，這樣能夠省去逐一配置 SSH 公鑰的麻煩。

但無論哪一種情形，Git 協議的配置設定都很簡單。基本上，只要以守護進程的形式運行該命令便可：

git daemon --reuseaddr --base-path=/opt/git/ /opt/git/

這裏的 --reuseaddr 選項表示在重啓服務前，不等以前的鏈接超時就當即重啓。而 --base-path 選項則容許克隆項目時沒必要給出完整路徑。最後面的路徑告訴 Git 守護進程容許開放給用戶訪問的倉庫目錄。假若有防火牆，則須要爲該主機的 9418 端口設置爲容許通訊。

以守護進程的形式運行該進程的方法有不少，但主要還得看用的是什麼操做系統。在 Ubuntu 主機上，能夠用 Upstart 腳本達成。編輯該文件：

/etc/event.d/local-git-daemon

加入如下內容：

start on startup
stop on shutdown
exec /usr/bin/git daemon \
    --user=git --group=git \
    --reuseaddr \
    --base-path=/opt/git/ \
    /opt/git/
respawn

出於安全考慮，強烈建議用一個對倉庫只有讀取權限的用戶身份來運行該進程 — 只須要簡單地新建一個名爲 git-ro 的用戶（譯註：新建用戶默認對倉庫文件不具有寫權限，但這取決於倉庫目錄的權限設定。務必確認git-ro 對倉庫只能讀不能寫。），並用它的身份來啓動進程。這裏爲了簡化，後面咱們仍是用以前運行 Gitosis 的用戶 ‘git’。

這樣一來，當你重啓計算機時，Git 進程也會自動啓動。要是進程意外退出或者被殺掉，也會自行重啓。在設置完成後，不重啓計算機就啓動該守護進程，能夠運行：

initctl start local-git-daemon

而在其餘操做系統上，能夠用 xinetd，或者 sysvinit 系統的腳本，或者其餘相似的腳本 — 只要能讓那個命令變爲守護進程並可監控。

接下來，咱們必須告訴 Gitosis 哪些倉庫容許經過 Git 協議進行匿名只讀訪問。若是每一個倉庫都設有各自的段落，能夠分別指定是否容許 Git 進程開放給用戶匿名讀取。好比容許經過 Git 協議訪問 iphone_project，能夠把下面兩行加到gitosis.conf 文件的末尾：

[repo iphone_project]
daemon = yes

在提交和推送完成後，運行中的 Git 守護進程就會響應來自 9418 端口對該項目的訪問請求。

若是不考慮 Gitosis，單單起了 Git 守護進程的話，就必須到每個容許匿名只讀訪問的倉庫目錄內，建立一個特殊名稱的空文件做爲標誌：

$ cd /path/to/project.git
$ touch git-daemon-export-ok

該文件的存在，代表容許 Git 守護進程開放對該項目的匿名只讀訪問。

Gitosis 還能設定哪些項目容許放在 GitWeb 上顯示。先打開 GitWeb 的配置文件 /etc/gitweb.conf，添加如下四行：

$projects_list = "/home/git/gitosis/projects.list";
$projectroot = "/home/git/repositories";
$export_ok = "git-daemon-export-ok";
@git_base_url_list = ('git://gitserver');

接下來，只要配置各個項目在 Gitosis 中的 gitweb 參數，便能達成是否容許 GitWeb 用戶瀏覽該項目。好比，要讓 iphone_project 項目在 GitWeb 裏出現，把repo 的設定改爲下面的樣子：

[repo iphone_project]
daemon = yes
gitweb = yes

在提交併推送過以後，GitWeb 就會自動開始顯示 iphone_project 項目的細節和歷史。

4.10 Git 託管服務

若是不想經歷本身架設 Git 服務器的麻煩，網絡上有幾個專業的倉庫託管服務可供選擇。這樣作有幾大優勢：託管帳戶的創建一般比較省時，方便項目的啓動，並且不涉及服務器的維護和監控。即便內部建立並運行着本身的服務器，同時爲開源項目提供一個公共託管站點仍是有好處的 — 讓開源社區更方便地找到該項目，並給予幫助。

目前，可供選擇的託管服務數量繁多，各有利弊。在 Git 官方 wiki 上的 Githosting 頁面有一個最新的託管服務列表：

http://git.or.cz/gitwiki/GitHosting

因爲本書沒法所有一一介紹，而本人（譯註：指本書做者 Scott Chacon。）恰好在其中一家公司工做，因此接下來咱們將會介紹如何在 GitHub 上創建新帳戶並啓動項目。至於其餘託管服務大致也是這麼一個過程，基本的想法都是差很少的。

GitHub 是目前爲止最大的開源 Git 託管服務，而且仍是少數同時提供公共代碼和私有代碼託管服務的站點之一，因此你能夠在上面同時保存開源和商業代碼。事實上，本書就是放在 GitHub 上合做編著的。（譯註：本書的翻譯也是放在 GitHub 上普遍協做的。）

GitHub

GitHub 和大多數的代碼託管站點在處理項目命名空間的方式上略有不一樣。GitHub 的設計更側重於用戶，而不是徹底基於項目。也就是說，若是我在 GitHub 上託管一個名爲grit 的項目的話，它的地址不會是 github.com/grit，而是按在用戶底下 github.com/shacon/grit （譯註：本書做者 Scott Chacon 在 GitHub 上的用戶名是shacon。）。不存在所謂某個項目的官方版本，因此假如第一做者放棄了某個項目，它能夠無縫轉移到其它用戶的名下。

GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公司，但任何人均可以方便快捷地申請到一個免費帳戶，並在上面託管數量不限的開源項目。接下來咱們快速介紹一下 GitHub 的基本使用。

創建新帳戶

首先註冊一個免費帳戶。訪問 Pricing and Signup 頁面 http://github.com/plans 並點擊 Free acount 裏的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。

圖 4-2. GitHub 服務簡介頁面

選擇一個系統中還沒有使用的用戶名，提供一個與之相關聯的電郵地址，並輸入密碼（見圖 4-3）：

圖 4-3. GitHub 用戶註冊表單

若是方便，如今就能夠提供你的 SSH 公鑰。咱們在前文的」小型安裝」一節介紹過生成新公鑰的方法。把新生成的公鑰複製粘貼到 SSH Public Key 文本框中便可。要是對生成公鑰的步驟不太清楚，也能夠點擊「explain ssh keys」連接，會顯示各個主流操做系統上完成該步驟的介紹。點擊「I agree，sign me up」按鈕完成用戶註冊，並轉到該用戶的 dashboard 頁面（見圖 4-4）:

圖 4-4. GitHub 的用戶面板

接下來就能夠創建新倉庫了。

創建新倉庫

點擊用戶面板上倉庫旁邊的「create a new one」連接，顯示 Create a New Repository 的表單（見圖 4-5）：

圖 4-5. 在 GitHub 上創建新倉庫

固然，項目名稱是必不可少的，此外也能夠適當描述一下項目的狀況或者給出官方站點的地址。而後點擊「Create Repository」按鈕，新倉庫就創建起來了（見圖 4-6）：

圖 4-6. GitHub 上各個項目的概要信息

因爲還沒有提交代碼，點擊項目地址後 GitHub 會顯示一個簡要的指南，告訴你如何新建一個項目並推送上來，如何從現有項目推送，以及如何從一個公共的 Subversion 倉庫導入項目（見圖 4-7）：

圖 4-7. 新倉庫指南

該指南和本書前文介紹的相似，對於新的項目，須要先在本地初始化爲 Git 項目，添加要管理的文件並做首次提交：

$ git init
$ git add .
$ git commit -m 'initial commit'

而後在這個本地倉庫內把 GitHub 添加爲遠程倉庫，並推送 master 分支上來：

$ git remote add origin git@github.com:testinguser/iphone_project.git
$ git push origin master

如今該項目就託管在 GitHub 上了。你能夠把它的 URL 分享給每位對此項目感興趣的人。本例的 URL 是http://github.com/testinguser/iphone_project。而在項目頁面的摘要部分，你會發現有兩個 Git URL 地址（見圖 4-8）：

圖 4-8. 項目摘要中的公共 URL 和私有 URL

Public Clone URL 是一個公開的，只讀的 Git URL，任何人均可以經過它克隆該項目。能夠隨意散播這個 URL，好比發佈到我的網站之類的地方等等。

Your Clone URL 是一個基於 SSH 協議的可讀可寫 URL，只有使用與上傳的 SSH 公鑰對應的密鑰來鏈接時，才能經過它進行讀寫操做。其餘用戶訪問該項目頁面時只能看到以前那個公共的 URL，看不到這個私有的 URL。

從 Subversion 導入項目

若是想把某個公共 Subversion 項目導入 Git，GitHub 能夠幫忙。在指南的最後有一個指向導入 Subversion 頁面的連接。點擊它會看到一個表單，包含有關導入流程的信息以及一個用來粘貼公共 Subversion 項目鏈接的文本框（見圖 4-9）：

圖 4-9. Subversion 導入界面

若是項目很大，採用非標準結構，或者是私有的，那就沒法藉助該工具實現導入。到第 7 章，咱們會介紹如何手工導入複雜工程的具體方法。

添加協做開發者

如今把團隊裏的其餘人也加進來。若是 John，Josie 和 Jessica 都在 GitHub 註冊了帳戶，要賦予他們對該倉庫的推送權限，能夠把他們加爲項目協做者。這樣他們就能夠經過各自的公鑰訪問個人這個倉庫了。

點擊項目頁面上方的「edit」按鈕或者頂部的 Admin 標籤，進入該項目的管理頁面（見圖 4-10）：

圖 4-10. GitHub 的項目管理頁面

爲了給另外一個用戶添加項目的寫權限，點擊「Add another collaborator」連接，出現一個用於輸入用戶名的表單。在輸入的同時，它會自動跳出一個符合條件的候選名單。找到正確用戶名以後，點 Add 按鈕，把該用戶設爲項目協做者（見圖 4-11）：

圖 4-11. 爲項目添加協做者

添加完協做者以後，就能夠在 Repository Collaborators 區域看到他們的名單（見圖 4-12）：

圖 4-12. 項目協做者名單

若是要取消某人的訪問權，點擊「revoke」便可取消他的推送權限。對於未來的項目，你能夠從現有項目複製協做者名單，或者直接借用協做者羣組。

項目頁面

在推送或從 Subversion 導入項目以後，你會看到一個相似圖 4-13 的項目主頁：

圖 4-13. GitHub 上的項目主頁

別人訪問你的項目時看到的就是這個頁面。它有若干導航標籤，Commits 標籤用於顯示提交歷史，最新的提交位於最上方，這和 git log 命令的輸出相似。Network 標籤展現全部派生了該項目並作出貢獻的用戶的關係圖譜。Downloads 標籤容許你上傳項目的二進制文件，提供下載該項目各個版本的 tar/zip 包。Wiki 標籤提供了一個用於撰寫文檔或其餘項目相關信息的 wiki 站點。Graphs 標籤包含了一些可視化的項目信息與數據。默認打開的 Source 標籤頁面，則列出了該項目的目錄結構和概要信息，並在下方自動展現 README 文件的內容（若是該文件存在的話），此外還會顯示最近一次提交的相關信息。

派生項目

若是要爲一個本身沒有推送權限的項目貢獻代碼，GitHub 鼓勵使用派生（fork）。到那個感興趣的項目主頁上，點擊頁面上方的「fork」按鈕，GitHub 就會爲你複製一份該項目的副本到你的倉庫中，這樣你就能夠向本身的這個副本推送數據了。

採起這種辦法的好處是，項目擁有者沒必要忙於應付賦予他人推送權限的工做。隨便誰均可以經過派生獲得一個項目副本並在其中展開工做，過後只須要項目維護者將這些副本倉庫加爲遠程倉庫，而後提取更新合併便可。

要派生一個項目，到原始項目的頁面（本例中是 mojombo/chronic）點擊「fork」按鈕（見圖 4-14）：

圖 4-14. 點擊「fork」按鈕得到任意項目的可寫副本

幾秒鐘以後，你將進入新建的項目頁面，會顯示該項目派生自哪個項目（見圖 4-15）：

圖 4-15. 派生後獲得的項目副本

GitHub 小結

關於 GitHub 就先介紹這麼多，可以快速達成這些事情很是重要（譯註：門檻的下降和完成基本任務的簡單高效，對於推進開源項目的協做發展有着舉足輕重的意義。）。短短几分鐘內，你就能建立一個新帳戶，添加一個項目並開始推送。若是項目是開源的，整個龐大的開發者社區均可以當即訪問它，提供各式各樣的幫助和貢獻。最起碼，這也是一種 Git 新手當即體驗嘗試 Git 的捷徑。