gitリポジトリをホストするのにWebDAV使わないほうがいい
共有gitリポジトリをホストする方法をググると、WebDAVを使ったやり方が結構出てくる。このやり方には明確なデメリットしか無いにもかかわらず、WebDAVを使ってホストする方法を紹介するページでは触れられていないことが多い。まったく大した話ではないが、開発者が二度とひっかからないためにリポジトリのホストにWebDAVを使わないほうがいい理由を書いておく。以下、2つ。
- WebDAVを通じてホストすると遅い
- WevDAVを通じてホストするとサーバサイドフックが起動しない
遅い
超遅い。ベンチマークを測ったわけではないが、sshでホストする場合と比べてcloneやpushやpullが3倍以上遅いのではないか。
WebDAVでホストすると遅くなってしまうのには理由があって、sshでホストする場合とWebDAVでホストする場合とでは、そもそもの通信プロトコルが違うから。pro gitを参照すると、HTTP経由の場合はdumb protocolという効率の悪い通信になるようだ。
無口なプロトコル
Git の over HTTPによる移行は、しばしば無口なプロトコル(dumb protocol)と言われます。なぜなら、トランスポートプロセスの最中に、サーバ側に関する Git 固有のコードは何も必要としないからです。フェッチプロセスは、一連の GET リクエストであり、クライアントはサーバ上の Gitレポジトリのレイアウトを推測することができます。
http://git-scm.com/book/ja/ch9-6.html
作業時にpushやpullがもたついたりするのは作業のリズムを壊してしまいがちだ。pushやpullは早くなければ開発者を妨害する。
サーバサイドフックが起動しない
遅いのは我慢すればなんとかなるかもしれないが、サーバサイドフックが一切起動しなくなるのは致命的だ。gitでは、各アクションごとにフックスクリプトを設定することができる。サーバサイドフックはその中でも共有リポジトリに対するアクションへのフックを設定できる。例えばpushした時にメールやIRCで通知を流してくれるのはこれのおかげだ。
複数人で開発する際に、pushの通知を受けとることは絶対必要だ。例えば、本番ブランチに対して誰かがpushしたことを通知して欲しい時が誰にでもきっと来る。しかしWebDAVを使っている限りそのたぐいのことが本当に一切できない。
ではどうすれば
2つ方法があって、最初からssh経由でホストするか、Smart HTTPを導入するかのどちらかだ。
ssh経由でホストする場合は、開発者全員がsshでログインできるサーバに共有用のリポジトリを置くだけで良い。一度共有リポジトリを作った後は、ssh://user@hostname/path/to/foo.gitでcloneできる。作り方も以下みたいにちょっとオプションを付けてgit initすればいいだけで簡単。
$ mkdir foo.git $ cd foo.git $ git init --bare --shared=true
開発者が全員ログインできるサーバがない、gitリポジトリ用のサーバのユーザを増やしたくない、鍵認証したいが鍵の管理がめんどくさい、リポジトリごとにpushできる開発者を制限したい、などの場合は、gitosisやgitoliteなどの専用の管理ツールを使うとよい。
gitosisやgitoliteなどのツールを利用すると、鍵と開発者の対応をサーバの一つのユーザ内で完結させた上でリポジトリやリポジトリのブランチごとにpushできる開発者を細かく制限できる。個人的にはブランチ単位で権限を細かく制御できるgitoliteがgitosisよりもおすすめ。
Smart HTTPでホストする
もうWebDAVを導入してしまって構成変えるのも面倒くさい場合は、Smart HTTPを導入することでWebDAVによるホストの欠点を完全に隠すことができる。速度もssh経由に劣らないし、サーバサイドフックも起動する。
Smart HTTPという大仰な呼ばれ方だが、導入方法は単にgit-http-backendというCGIを共有gitリポジトリをホストするサーバに設置するだけだ。ユーザは今まで通りcloneしたりpushしたりできるので、エンド開発者がリポジトリのアドレスを変えたりしなければならないなどの移行作業がまったくない。
pro gitを参照するとSmart HTTPの導入について書いてある。
結論
バージョン管理システムにかぎらず複数人で開発する際のインフラとなるものは、それがヘボければ開発者の作業を妨害するし、優れていれば開発者みんなを気持ちよくさせてくれる。