使用 Gitolite 搭建 Git 服務器

Gitolite 是在 Git 之上的一個受權層，依託 sshd 或者 httpd 來進行認證。（認證是肯定用戶是誰，受權是決定該用戶是否被容許作他想作的事情）。

經過 Gitolite 你能夠設置訪問權限，不僅做用於倉庫，還能夠做用到每一個 branch 和 tag name。你能夠定義確切的人(或一組人)只能 push 特定的 "refs" (或者 branches 或者 tags )。

寫在前面

若是你熟悉 Git 和 SVN 的區別，相信你不會認爲 Git 服務器有多複雜。而事實上，搭建一個無需受權管理的Git服務器確實很簡單。由於這個服務器僅僅是一個遠程裸倉庫（無工做區），用來做爲24小時開機的交換中心而已。若是你的需求如此簡單，推薦學習 廖雪峯 《Git 教程》中的 搭建 Git 服務器 一節。

若是你還沒離開，那接下來，咱們聊聊 Git 的權限管理這點事兒。Git 自己是不支持權限控制的，可能它也不想這麼作。因爲 Git 支持鉤子（hook），所以能夠在服務器端編寫一系列腳原本控制 Git 的各類操做，達到權限控制的目的。

Gitolite 只是 Git 權限管理工具中的一種，具備一樣功能的還有：

• GitLab 能夠說是 GitHub 的開源版本，一開始是使用 Gitolite 做爲受權管理的解決方案，後來由於兩個項目的開發和同步等方面出現問題，在2013年2月，GitLab 宣佈與 Gitolite 分道揚鑣。總之，GitLab 是一個重量級的版本，要使用它，你須要安裝不少額外的軟件，如 PostgreSQL, Redis, Sidekiq, Unicorn, nginx and gitlab-shell 等。因此說，它是資源密集型的，但功能確實強大，也更有利於開發團隊的高效率協做，比較適合大型團隊。

• Gitosis 和 Gitolite 沒什麼區別，只是這個項目已經中止維護了，因此我也懶得去費時間進行了解，這裏只是提一下。

• 其餘 確定會有其餘的解決方案，只是我以爲知道以上的就足夠了。

簡單介紹

到如今咱們也只是知道，Gitolite 是一款 Git 受權管理工具，那麼它具體是怎樣的呢？咱們姑且從它的幾個特性來簡單瞭解下：

• 在服務器端，使用一個 unix 用戶做爲遠程訪問的對象

• 爲多用戶提供訪問權限，但他們不是真正的用戶，不會得到 shell 權限

• 控制對多個 git 倉庫的訪問，讀訪問被repo層控制，寫訪問在 branch/tag/file/directory 層控制，包括誰可以 rewind，create 以及 delete branches/tags

• 可以不通過root容許進行安裝，假設git和perl已經被安裝了 （這句話不懂，暫時直譯過來）？

• 認證一般採用sshd，可是也可使用httpd

• 可以簡化你的倉庫路徑，相似 GitHub 那樣，例如：git@your_server.com:your-project.git

開始搭建

1. （服務端） 切換到 root 身份

   `su - root`

2. （服務端） 安裝依賴

   `apt-get install git-core ssh`

3. （服務端） 建立一個用戶供 Gitolite 使用：

   `useradd --system --shell /bin/bash --create-home git`

4. （服務端） 設置密碼

   `passwd git`

5. （客戶端） 生成 SSH 公鑰並複製到服務器的 git 家目錄

   `cd ~`  
   
   `ssh-keygen`  
   
   `scp ~/.ssh/id_rsa.pub git@your_server:admin.pub`

6. （服務端） 安裝 Gitolite

   `su - git`
   
   `mkdir bin`
   
   `git clone git://github.com/sitaramc/gitolite.git`
   
   `~/gitolite/install -to ~/bin`
   
   \# 將你的公鑰 admin.php 設置爲 Gitolite 超級管理員  
   `~/bin/gitolite setup -pk ~/admin.pub`

7. （客戶端） 克隆神奇的受權管理倉庫

   \# 若是克隆成功，說明 Git 服務器已經搭建完成。  
   `git clone git@your_server:gitolite-admin`

使用方法

1. 添加 Gitolite 項目成員

   將項目成員經過 ssh-keygen 命令生成的公鑰文件重命名成惟一標識的文件，如macken.pub，而後放到 gitolite-admin/keydir 目錄下，add、commit、push以後，這樣新成員就算加入了。新成員默承認以克隆任何沒有被權限控制的倉庫，如 Gitolite 自帶的 "testing"。

2. 建立 Gitolite 項目倉庫

   倉庫的建立不須要你登陸服務端，只須要用編輯器打開 gitolite-admin/conf/gitolite.conf，加入兩行：

   repo new_repo

   RW = macken

   而後將變更提交到服務器，遠程的 Gitolite 就會自動幫你建立好一個空倉庫並分配給 macken 讀寫的權限。是否是很方便？

3. 項目受權管理

   • 要方便的進行受權，那就有必要將項目的成員分組：

     @admins = macken steven

     @interns = ashok

     @engineers = macken steven wally alice

     @staff = @admins @engineers

   • 能夠對倉庫的分支和標籤進行正則匹配受權：

     repo @oss_repos

     RW int$ = @interns

     RW eng- = @engineers

     RW refs/tags/rc[0-9] = @engineers

     RW+ = @admins

     interns 組只能對以 「int「 結尾的分支有讀寫權限；

     engineers 組能夠對以 「eng-「 開頭的分支以及該倉庫的 「rc[0-9]「 的標籤分支有讀寫權限；

     admins 組則對本倉庫全部的分支有讀寫權限，並且 「+」 表明能夠有強推的權限。

     其它更詳盡的受權設置請參閱 官方文檔

寫在最後

Git 是極具開源精神的分佈式版本控制系統，但並不意味着在 Git 基礎上加上受權控制是有什麼不妥，目的不在於防着誰，而在於明確職責劃分，方便協調管理，避免由於任何人均可以接觸全部代碼而產生沒必要要的麻煩。就像 GitHub 那樣，任何人均可以 fork 別人的項目，從而生成一個分支到本身的倉庫，但你沒法直接操道別人的 master 分支，只能由項目的建立者根據你提交的 PR 來進行 merge。這樣，纔是一個有秩序的開源實踐。

最後，推薦一篇關於 Git Workflow 的經典老文：A successful Git branching model。

原文連接： https://macken.me/article/use...