4.1 サーバー上のGit - プロトコル

ファイルベースのリポジトリの長所は、シンプルであること、そして既存のファイルパーミッションとネットワークアクセスを利用できることです。もしチーム全体がアクセスできる共有ファイルシステムを既に持っているなら、リポジトリのセットアップは非常に簡単です。共有アクセスが可能な場所にベアリポジトリのコピーを置き、他の共有ディレクトリと同じように読み書きパーミッションを設定します。この目的のためにベアリポジトリのコピーをエクスポートする方法については、サーバー上にGitを導入するで説明します。

これは、他の人の作業リポジトリからすぐに作業を取り込むのに良いオプションでもあります。あなたと同僚が同じプロジェクトで作業していて、同僚が何かを確認してほしい場合、git pull /home/john/projectのようなコマンドを実行する方が、同僚がリモートサーバーにプッシュしてあなたがそこからフェッチするよりも簡単なことがよくあります。

この方法の短所は、共有アクセスは基本的なネットワークアクセスよりも設定が難しく、複数の場所からアクセスしにくいという点です。自宅のラップトップからプッシュしたい場合、リモートディスクをマウントする必要がありますが、これはネットワークベースのアクセスに比べて難しく、遅くなる可能性があります。

何らかの共有マウントを使用している場合、これが必ずしも最速のオプションではないことを言及しておくことが重要です。ローカルリポジトリは、データへの高速アクセスがある場合にのみ高速です。NFS上のリポジトリは、同じサーバー上のSSH経由のリポジトリよりも遅いことがよくあり、Gitは各システムのローカルディスク上で実行できます。

最後に、このプロトコルは偶発的な損傷からリポジトリを保護しません。すべてのユーザーは「リモート」ディレクトリへの完全なシェルアクセスを持っており、内部のGitファイルを変更または削除してリポジトリを破損させることを防ぐものはありません。

Smart HTTPはSSHまたはGitプロトコルと非常によく似ていますが、標準のHTTPSポートで動作し、様々なHTTP認証メカニズムを使用できます。これは、SSHキーを設定する必要があるSSHのようなものよりも、ユーザーにとってしばしば簡単であることを意味します。なぜなら、ユーザー名/パスワード認証のようなものを使用できるからです。

現在ではGitを使用する最も一般的な方法になっているでしょう。なぜなら、git://プロトコルのように匿名でサービスを提供することもでき、SSHプロトコルのように認証と暗号化を伴ってプッシュすることもできるからです。これらのために異なるURLを設定する必要がなくなり、単一のURLで両方に対応できます。プッシュしようとしてリポジトリが認証を要求する場合（通常はそうあるべきです）、サーバーはユーザー名とパスワードの入力を促すことができます。読み取りアクセスも同様です。

実際、GitHubのようなサービスでは、オンラインでリポジトリを表示するために使用するURL（例えばhttps://github.com/schacon/simplegit）は、クローンするためにも、そしてアクセス権があればプッシュするためにも使用できる同じURLです。

サーバーがGit HTTPスマートサービスで応答しない場合、GitクライアントはよりシンプルなDumb HTTPプロトコルにフォールバックしようとします。Dumbプロトコルは、ベアGitリポジトリがWebサーバーから通常のファイルとして提供されることを期待します。Dumb HTTPの利点は、その設定の単純さにあります。基本的に、ベアGitリポジトリをHTTPドキュメントルートの下に置き、特定のpost-updateフックを設定するだけで完了です（Gitフックを参照）。その時点から、リポジトリを置いたWebサーバーにアクセスできる人なら誰でも、そのリポジトリをクローンできるようになります。HTTP経由でリポジトリへの読み取りアクセスを許可するには、次のようにします。

これだけです。Gitにデフォルトで付属しているpost-updateフックは、HTTPでのフェッチとクローンが適切に機能するように、適切なコマンド（git update-server-info）を実行します。このコマンドは、このリポジトリにプッシュする（おそらくSSH経由で）ときに実行されます。そうすれば、他のユーザーは次のようにクローンできます。

この特定のケースでは、Apacheの設定で一般的な/var/www/htdocsパスを使用していますが、任意の静的ウェブサーバーを使用できます。ベアリポジトリをそのパスに置くだけです。Gitデータは基本的な静的ファイルとして提供されます（どのように提供されるかの詳細はGitの内側の章を参照してください）。

一般的には、読み書き可能なSmart HTTPサーバーを運用するか、単にDumb方式でファイルを読み取り専用でアクセス可能にするかのどちらかを選択します。両方のサービスを混在させることは稀です。

ここでは、HTTPプロトコルのSmart版の長所に焦点を当てます。

あらゆる種類のアクセスに単一のURLを使用でき、認証が必要な場合にのみサーバーがプロンプトを表示するというシンプルさは、エンドユーザーにとって非常に簡単です。ユーザーがローカルでSSHキーを生成し、その公開鍵をサーバーにアップロードしてから操作を開始する必要がないため、ユーザー名とパスワードで認証できることもSSHに対する大きな利点です。技術に詳しくないユーザーや、SSHがあまり一般的でないシステムを使用しているユーザーにとっては、これは使いやすさの点で大きな利点です。また、SSHプロトコルと同様に、非常に高速で効率的なプロトコルでもあります。

HTTPS経由でリポジトリを読み取り専用で提供することも可能です。これはコンテンツ転送を暗号化できることを意味します。さらに、クライアントに特定の署名付きSSL証明書を使用させることもできます。

もう一つの良い点は、HTTPとHTTPSは非常に広く使われているプロトコルであるため、企業のファイアウォールはこれらのポートからのトラフィックを許可するように設定されていることが多いということです。

HTTPS経由のGitは、一部のサーバーではSSHに比べてセットアップが少し厄介な場合があります。それ以外では、Gitコンテンツの提供において他のプロトコルがSmart HTTPに比べて大きな利点を持つことはほとんどありません。

認証付きプッシュにHTTPを使用する場合、認証情報の提供はSSH経由でキーを使用するよりも複雑になることがあります。ただし、macOSのキーチェーンアクセスやWindowsのCredential Managerなど、いくつかの認証情報キャッシュツールを使用することで、これをかなり簡単に行うことができます。システム上で安全なHTTPパスワードキャッシュを設定する方法については、認証情報の保存を参照してください。

SSHを使用する利点は多数あります。まず、SSHは比較的簡単にセットアップできます。SSHデーモンは一般的であり、多くのネットワーク管理者はそれらの経験を持ち、多くのOSディストリビューションはそれらで設定されているか、管理ツールを持っています。次に、SSH経由のアクセスは安全です。すべてのデータ転送が暗号化され、認証されます。最後に、HTTPS、Git、ローカルプロトコルと同様に、SSHは効率的であり、データを転送する前に可能な限りコンパクトにします。

SSHのマイナス面は、Gitリポジトリへの匿名アクセスをサポートしていないことです。SSHを使用する場合、人々は読み取り専用のアクセスであっても、あなたのマシンへのSSHアクセスを持っている必要があります。これは、単にリポジトリをクローンして調べたいだけのオープンソースプロジェクトにはSSHが向かないことを意味します。社内ネットワーク内でのみ使用する場合、SSHが唯一扱うべきプロトコルかもしれません。プロジェクトへの匿名読み取り専用アクセスを許可し、かつSSHも使用したい場合、あなたがプッシュするためにSSHを設定する必要がありますが、他の人がフェッチするためには別の何かを設定する必要があります。

Gitプロトコルは、利用可能なネットワーク転送プロトコルの中でしばしば最も高速です。公開プロジェクトで大量のトラフィックを処理している場合や、読み取りアクセスにユーザー認証を必要としない非常に大きなプロジェクトをホストしている場合、Gitデーモンを設定してプロジェクトを提供したいと考えるでしょう。これはSSHプロトコルと同じデータ転送メカニズムを使用しますが、暗号化と認証のオーバーヘッドはありません。

TLSやその他の暗号化がないため、git://経由でのクローンは任意のコード実行の脆弱性につながる可能性があり、何をしているのか理解している場合を除き、避けるべきです。

また、認証がないため、誰でもリポジトリをクローンできます（ただし、これは多くの場合、まさに望ましいことです）。セットアップも恐らく最も難しいプロトコルです。独自のデーモンを実行する必要があり、xinetdやsystemdなどの設定が必要で、これは常に簡単なことではありません。また、企業のファイアウォールが常に許可する標準ポートではないポート9418へのファイアウォールアクセスも必要です。大規模な企業ファイアウォールの背後では、この不明瞭なポートは一般的にブロックされます。