なぜ必要なのですか？
このタスクのネイティブgitツールは今日では明らかに不十分です：ネイティブgitプロトコルには認証ツールが含まれていません.sshを使用するには、OSに本格的なユーザーが必要です（シェルを使用）。これは常に適切で望ましいものではありません。
gitoliteを使用すると、OSでのアカウントの可用性に関係なくユーザーを作成し、柔軟に権限を付与できます。
前提条件
- トピックは大きいです。 したがって、すべての可能性からはほど遠い。
- 彼のドキュメントでは、gitolite開発者は、公開鍵による認証を使用してsshを操作する原理の理解不足から生じる膨大な数の問題に言及しています。 したがって、この問題に多少「水泳」している場合-記事の最後に小さなハウツーがあります。
- この記事では、gitoliteをインストールするように設計されたサーバーがUNIX系システムで実行されることを前提としています。
設置
実際、ほとんどの場合、インストールによって問題は発生しません。
サーバー上：
- システムで新しいユーザーを開始します。 便宜上、gitと呼びましょう。
- 管理者となるユーザーの公開キーをgitユーザーのホームフォルダーにコピーします。 キー名は.pub形式である必要があることに注意してください。ここで、gitoliteはどのようにあなたを知っているのでしょうか。 この名前はどのシステム名とも一致しない場合があります。 gitoliteにgitadminとして認識させるには、キーファイルの名前をgitadmin.pubに変更する必要があります
gitユーザーとしてログインし、gitoliteをインストールします。
su git cd ~ git clone git://github.com/sitaramc/gitolite gitolite/src/gl-system-install gl-setup -q ~/gitadmin.pub
カスタマイズ
gitoliteのセットアップの特徴は、gitoliteを構成する操作がサーバー上で直接実行されることはほとんどないことです。 新しいユーザー、リポジトリを追加、またはアクセス権を変更するには、特別なgitolite-adminリポジトリのgit cloneを作成し、変更を加えてgit pushを行う必要があります。 事実、ジトライトはこれらの変更を有効にするためにフックのシステム全体を使用しています。
したがって、新しいリポジトリを作成し、必要なユーザーを追加するには、次のものが必要です。
- インストール時に公開キーがgitoliteに追加されたユーザー（またはgitolite-adminリポジトリに対する十分な権限を持つ他のユーザー）から、次を実行します。
git clone git@server:gitolite-admin
これにより、現在のフォルダーに管理リポジトリのコピーが作成されます。 confとkeydirの2つのフォルダーで構成されます。 confフォルダーには、リポジトリーとそれらへのアクセス権のリストを含むgitolite.confファイルが含まれています。 keydirフォルダー内で、gitoliteが知っておくべきユーザーの公開鍵。 - 新しいユーザーを追加するには、keydirフォルダーに公開キーを書き込むだけです。 .pubの末尾までのキー名は、gitoliteシステムのユーザー名になります。 例：user1.pubまたはjohn-smith.pub。 名前にはドットとアンダースコア文字を使用できます。
- リポジトリを追加して権限を変更するには、conf / gitolite.confファイルを編集します。 最初は、次のようになります。
repo gitolite-admin RW+ = gitadmin repo testing RW+ = @all
行を追加します。
repo megaproject RW+ = gitadmin user1 john-smith
これらの行は、ユーザーgitadmin、user1、john-smithが権限を持つ新しいメガプロジェクトリポジトリを説明しています。 - 次に、すべての変更を適用して送信します。
git add . git commit -a -m "New repo and users added" git push
構成ファイル形式に関するいくつかの言葉：
- グループを使用することは可能です。 そして、ユーザーとリポジトリの両方。 例：
@oss_repos = gitolite linux git perl rakudo entrans vkc @staff = sitaram some_dev another-dev
allは特別な事前定義されたグループです。 コンテキストに応じて、すべての認証されたユーザー、またはすべてのリポジトリについて説明します。
- 基本的な権限は次のとおりです。
- R-読み取りを許可します
- RW-既存の参照にプッシュするか、新しい参照を作成できます
- RW +--fをプッシュしたり、refを削除したりできます（つまり、情報を破棄します）
- -（マイナス）-アクセスを拒否
新しく作成されたリポジトリを操作する
実際に、ユーザーの観点からジトライトを操作することは完全に伝統的です。 この例に従って、開発者はコマンドを実行できます。
git clone git@server:megaproject cd megaproject touch newfile git add . git commit -a -m "newfile" git push git@server:megaproject master
ssh-公開鍵認証
ご存知かもしれませんが、sshでは、従来のパスワード認証に加えて、キーペアを使用して渡すことができます。 公開鍵認証は、鍵ペアを生成し、自分を認識する必要のあるホストに公開鍵を提供する場合です。 その後、sshを使用して、パスワードを入力せずにリモートマシンに入ることができます。
ユーザーのキーペアを生成するには、次を実行します。
ssh-keygen -t rsa
このコマンドは、〜/ .sshフォルダーにid_rsaとid_rsa.pubの2つのファイルを作成します。 最初は秘密鍵であり、これは一見の価値があります。2番目（拡張子は.pub）は公開鍵で、リモートホストに転送する必要があります。 実際、このファイル内には、テキストとして単純に送信できる長いテキスト文字列が1つだけあります。
アクセスを提供するマシンで、指定したキーを、アクセスを整理する必要があるユーザーの〜/ .ssh / authorized_keysファイルに入力する必要があります。
ジトライト-動作原理
これは、一般的にどのように配置されるかに興味がある人向けです。 実際、説明からすでに明らかなように、gitoliteは公開鍵経由の認証を使用してssh上で動作します（より正確には、これが最も一般的な構成です）。
リポジトリを使用した作業が行われるサーバー上の唯一の実際のユーザーが開始されます。 そして、gitoliteの「魔法」は、これらのキーがオプション「command = [path] / gl-auth-command ...」でauthorized_keysに入ることです。 このオプションは、ユーザーが実際に実行したいものに関係なく、指定されたコマンドを実行するようにsshサーバーに指示します。 この場合、元のコマンドはSSH_ORIGINAL_COMMAND変数に格納され、gitoliteが読み取って必要なものを見つけます。 - インストール時に公開キーがgitoliteに追加されたユーザー（またはgitolite-adminリポジトリに対する十分な権限を持つ他のユーザー）から、次を実行します。