章 ▾ 第2版

10.6 Gitの内側 - 転送プロトコル

転送プロトコル

Gitは、2つの主要な方法で2つのリポジトリ間でデータを転送できます。「ダム」プロトコルと「スマート」プロトコルです。このセクションでは、これら2つの主要なプロトコルがどのように動作するかを簡単に説明します。

ダムプロトコル

HTTP経由で読み取り専用として提供されるリポジトリをセットアップする場合、ダムプロトコルが使用される可能性が高いです。このプロトコルが「ダム」と呼ばれるのは、転送プロセス中にサーバー側にGit固有のコードを必要としないためです。フェッチプロセスは一連のHTTP GET リクエストであり、クライアントはサーバー上のGitリポジトリのレイアウトを想定できます。

注

ダムプロトコルは今日ではほとんど使用されていません。セキュリティを確保したり、プライベートにしたりするのが難しいため、ほとんどのGitホスト（クラウドベースとオンプレミスを問わず）は使用を拒否します。通常、この後で説明するスマートプロトコルを使用することをお勧めします。

simplegitライブラリのhttp-fetchプロセスを追ってみましょう

$ git clone http://server/simplegit-progit.git

このコマンドが最初に行うことは、info/refsファイルをダウンロードすることです。このファイルはupdate-server-infoコマンドによって書き込まれるため、HTTP転送を正しく機能させるには、これをpost-receiveフックとして有効にする必要があります。

=> GET info/refs
ca82a6dff817ec66f44342007202690a93763949     refs/heads/master

これでリモートリファレンスとSHA-1のリストが手に入りました。次に、HEADリファレンスが何であるかを確認し、作業が完了したときに何をチェックアウトすればよいかを知ります。

=> GET HEAD
ref: refs/heads/master

プロセスが完了したら、masterブランチをチェックアウトする必要があります。この時点で、ウォークプロセスを開始する準備ができています。info/refsファイルで見たca82a6コミットオブジェクトが開始点なので、まずそれをフェッチします。

=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
(179 bytes of binary data)

オブジェクトが返されます。そのオブジェクトはサーバー上でルーズフォーマットであり、静的なHTTP GETリクエストを介してフェッチされました。それをzlibで解凍し、ヘッダーを剥がして、コミットの内容を見ることができます。

$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
author Scott Chacon <schacon@gmail.com> 1205815931 -0700
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700

Change version number

次に、さらに2つのオブジェクトを取得する必要があります。cfda3bは、先ほど取得したコミットが指すコンテンツツリーであり、085bb3は親コミットです。

=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
(179 bytes of data)

これで次のコミットオブジェクトが得られます。ツリーオブジェクトを取得します。

=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
(404 - Not Found)

おっと、そのツリーオブジェクトはサーバー上でルーズフォーマットではないようです。そのため、404応答が返されます。これにはいくつかの理由があります。オブジェクトが別のリポジトリにあるか、このリポジトリのパックファイルにある可能性があります。Gitはまず、リストされている代替をチェックします。

=> GET objects/info/http-alternates
(empty file)

これが代替URLのリストを返した場合、Gitはそこでルーズファイルとパックファイルをチェックします。これは、互いにフォークしているプロジェクトがディスク上のオブジェクトを共有するための優れたメカニズムです。ただし、このケースでは代替がリストされていないため、オブジェクトはパックファイルにあるはずです。このサーバーで利用可能なパックファイルを確認するには、それらのリストを含むobjects/info/packsファイルを取得する必要があります（これもupdate-server-infoによって生成されます）。

=> GET objects/info/packs
P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack

サーバー上にはパックファイルが1つしかないため、オブジェクトがそこにあるのは明らかですが、念のためインデックスファイルを確認します。これは、サーバー上に複数のパックファイルがある場合にも役立ち、必要なオブジェクトが含まれているパックファイルを確認できます。

=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
(4k of binary data)

パックファイルのインデックスが手に入ったので、オブジェクトがそこにあるかどうかを確認できます。インデックスには、パックファイルに含まれるオブジェクトのSHA-1と、それらのオブジェクトへのオフセットがリストされているからです。オブジェクトはそこにあるので、パックファイル全体を取得してください。

=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
(13k of binary data)

ツリーオブジェクトが手に入ったので、コミットのウォークを続けます。それらもすべて、先ほどダウンロードしたパックファイル内に含まれているため、サーバーにこれ以上リクエストを行う必要はありません。Gitは、最初にダウンロードしたHEADリファレンスが指していたmasterブランチの作業コピーをチェックアウトします。

スマートプロトコル

ダムプロトコルはシンプルですが、少し非効率的で、クライアントからサーバーへのデータ書き込みを処理できません。スマートプロトコルはより一般的なデータ転送方法ですが、リモート側にGitに精通したプロセスが必要です。これにより、ローカルデータを読み取り、クライアントが持っているものと必要なものを把握し、カスタムパックファイルを生成できます。データ転送には、データをアップロードするための一組と、データをダウンロードするための一組の、2つのプロセスセットがあります。

データアップロード

リモートプロセスにデータをアップロードするために、Gitはsend-packとreceive-packプロセスを使用します。send-packプロセスはクライアントで実行され、リモート側のreceive-packプロセスに接続します。

SSH

例えば、プロジェクトでgit push origin masterを実行し、originがSSHプロトコルを使用するURLとして定義されているとします。Gitはsend-packプロセスを起動し、SSH経由でサーバーへの接続を開始します。次のようなSSH呼び出しを介して、リモートサーバー上でコマンドを実行しようとします。

$ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
00a5ca82a6dff817ec66f4437202690a93763949 refs/heads/master□report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1+github-607-gfba4028 delete-refs
0000

git-receive-packコマンドは、現在持っている各リファレンスについて1行で即座に応答します。この場合、masterブランチとそのSHA-1だけです。最初の行には、サーバーの機能リストも含まれています（ここでは、report-status、delete-refs、およびクライアント識別子を含むその他の機能）。

データはチャンクで送信されます。各チャンクは、チャンクの長さ（長さ自体の4バイトを含む）を指定する4文字の16進値で始まります。チャンクには通常、1行のデータと末尾の改行が含まれます。最初のチャンクは00a5で始まります。これは16進数で165を意味し、チャンクが165バイトであることを示します。次のチャンクは0000で、サーバーがリファレンスリストの処理を完了したことを意味します。

サーバーの状態がわかったので、send-packプロセスは、サーバーが持っていないコミットが何であるかを判断します。このプッシュで更新される各リファレンスについて、send-packプロセスはその情報をreceive-packプロセスに伝えます。例えば、masterブランチを更新し、experimentブランチを追加する場合、send-packの応答は次のようになります。

0076ca82a6dff817ec66f44342007202690a93763949 15027957951b64cf874c3557a0f3547bd83b3ff6 \
	refs/heads/master report-status
006c0000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d \
	refs/heads/experiment
0000

Gitは、更新している各リファレンスについて、行の長さ、古いSHA-1、新しいSHA-1、および更新されるリファレンスを含む行を送信します。最初の行にはクライアントの機能も含まれています。すべての「0」のSHA-1値は、以前には何もなかったことを意味します。これは、experimentリファレンスを追加しているためです。リファレンスを削除する場合は、その逆、つまり右側にすべて「0」が表示されます。

次に、クライアントはサーバーがまだ持っていないすべてのオブジェクトのパックファイルを送信します。最後に、サーバーは成功（または失敗）の表示で応答します。

000eunpack ok
HTTP(S)

このプロセスはHTTP経由でもほとんど同じですが、ハンドシェイクが少し異なります。接続は次のリクエストで開始されます。

=> GET http://server/simplegit-progit.git/info/refs?service=git-receive-pack
001f# service=git-receive-pack
00ab6c5f0e45abd7832bf23074a333f739977c9e8188 refs/heads/master□report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1~vmg-bitmaps-bugaloo-608-g116744e
0000

これで最初のクライアントとサーバー間のやり取りは終わりです。次にクライアントは、今度はPOSTリクエストを送信し、send-packが提供するデータを含めます。

=> POST http://server/simplegit-progit.git/git-receive-pack

POSTリクエストには、send-packの出力とパックファイルがペイロードとして含まれます。その後、サーバーはHTTP応答で成功または失敗を示します。

HTTPプロトコルは、このデータをチャンク転送エンコーディング内にさらにラップする可能性があることに留意してください。

データダウンロード

データをダウンロードする場合、fetch-packとupload-packプロセスが関与します。クライアントはfetch-packプロセスを開始し、リモート側のupload-packプロセスに接続して、どのデータが転送されるかをネゴシエートします。

SSH

SSH経由でフェッチを行う場合、fetch-packは次のように実行されます。

$ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"

fetch-packが接続すると、upload-packは次のようなものを返します。

00dfca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fe2409a098dc3e53539a9028a94b6224db9d6a6b6 refs/heads/master
0000

これはreceive-packが応答するものと非常によく似ていますが、機能が異なります。さらに、HEADが何を指しているか（symref=HEAD:refs/heads/master）を返すため、クライアントはこれがクローンである場合に何をチェックアウトすればよいかを知ることができます。

この時点で、fetch-packプロセスは持っているオブジェクトを調べ、「want」とその後に欲しいSHA-1を送信して、必要なオブジェクトで応答します。既に持っているすべてのオブジェクトは「have」とその後にSHA-1を付けて送信します。このリストの最後に「done」と書き込み、upload-packプロセスを開始して、必要なデータのパックファイルの送信を開始します。

003cwant ca82a6dff817ec66f44342007202690a93763949 ofs-delta
0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
0009done
0000
HTTP(S)

フェッチ操作のハンドシェイクには2つのHTTPリクエストが必要です。最初のものは、ダムプロトコルで使用されたのと同じエンドポイントへのGETです。

=> GET $GIT_URL/info/refs?service=git-upload-pack
001e# service=git-upload-pack
00e7ca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed no-done symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master
0000

これはSSH接続を介してgit-upload-packを呼び出すのと非常によく似ていますが、2番目のやり取りは別のリクエストとして実行されます。

=> POST $GIT_URL/git-upload-pack HTTP/1.0
0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7
0032have 441b40d833fdfa93eb2908e52742248faf0ee993
0000

これも上記と同じ形式です。このリクエストへの応答は成功または失敗を示し、パックファイルを含みます。

プロトコルのまとめ

このセクションでは、転送プロトコルのごく基本的な概要を説明しました。プロトコルには、multi_ackやside-band機能など、他にも多くの機能が含まれていますが、それらを説明することは本書の範囲外です。クライアントとサーバー間の一般的なやり取りの感覚を掴んでいただくことを目指しました。これ以上の知識が必要な場合は、Gitのソースコードを確認することをお勧めします。

scroll-to-top