使用 Gitolite 搭建 Git 伺服器

Macken發表於2016-09-19
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.pub 設定為 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-gitolite-bui...

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章