分散バージョン管理で間違いないって、ベイビー

From The Joel on Software Translation Project

Jump to: navigation, search

Joel Spolsky / 青木靖 訳

2010年3月17日 水曜


しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialGitのことを取り上げた。

そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」

17taco2-thumbnail.JPG

タコーの今の様子

わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちらかで、あるいは細かい部分と趣旨が両方間違っていることもあるが、あの時に関しては根本的に間違っていた。ストロベリーピザみたいに、あるいはハラペニョドーナツみたいに、間違っていたのだ。

あのポッドキャストのだいぶ以前に、私たちの開発チームはMercurialに切り替えていた。そしてその切り替えで私はすっかり混乱させられた。そのためコードのチェックインをしてもらうために専門家を雇っていたほどだ(真に受けないでね)。しばらくの間は手探りで、いくつかの基本コマンドを覚えたり、Subversionと同じような仕組みだろうと想像したりしていたが、何かSubversionと同じようにいかないことがあると、混乱してしまい、大抵は部屋を出てベンジャミンやジェイコブの助けを求めに行くことになった。

そのうち、開発チームの連中がこんなことを言い始めた。あのさ、あのMercurialってすごいよ。Mercurialと一緒に使えるコードレビューツールを作りたいんだ。それだけじゃなくて、そのためのサポートやホスティングサービスには結構な需要があるんじゃないかと思うよ(Mercurial自体はGPLライセンスの元で無料で手に入るが、何かを使い始める前に何らかのサポートを求める企業というのはたくさんあるものだ)。

私は「何を言ってるんだ?」と思ったけど、ご存じのように会社で本当に決断を下しているのは私じゃない。「マネジメントはサポート機能」なのだから。それで彼らは6人のインターンを全部引っ張っていき、Mercurialをベースにして、その製品を作り始めた。

この「分散バージョン管理」というやつがどんな仕組みで動いているのか、ちゃんと理解しておいた方がいいなと思った。うちの会社で売っているらしい製品について人に聞かれたときにもし答えられなかったりしたら、またぞろブロゴスフィアで誰かが、私がサメをどうしたとかこき下ろす記事を書くに違いない。

だから調べて、調べて、最後にはそれが何なのか理解した。みんなにもそれについて教えてあげたいと思う。

分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。

重要なのは、このシステムが「バージョン」ではなく「変更」で物事を捉えているということだ。

こんな風に言うのが何か禅問答じみているのはわかっている。従来のバージョン管理では、「これがバージョン1だ。それからこれがバージョン2。今度のはバージョン3だ」という風に考える。

一方分散バージョン管理では、最初何もない。それから変更が来る。それからまた別な変更がくる。

これは異なるプログラムモデルであり、ユーザモデルを変える必要がある。

Subversionでは、「ローカルのバージョンをメインバージョンに更新しよう」とか、「前のバージョンに戻そう」などと考える。

17taco-thumbnail.JPG

一方Mercurialでは、「ジェイコブのチェンジセットをくれ」とか、「あのチェンジセットのことは忘れることにしよう」と考えるのだ。

SubversionのマインドセットのままMercurialにやってくると、大概のことはうまくいくが、うまくいかないところで混乱してしまい、惨めで失敗した気分になり、Mercurialを嫌いになるだろう。

しかし心を自由にしてバージョン管理というものについて考え直し、「バージョンを管理する」という考え方と、「変更を管理する」という考え方の違いの本質が見えるようになると、視野が明るくなって幸せな気分になり、これこそバージョン管理が本来機能すべき仕方なのだと思うようになるだろう。

最初変に感じるのはわかる…なんせ1972年以来、みんな扱うべきはバージョンだと思ってきたのだ。しかし驚いたことに、変更自体をファーストクラスの要素として捉えると、非常に重要な問題が解決することがわかったのだ。ブランチさせたコードをマージするという問題だ。

これが一番肝心な点であり、実際開発者の生産性についてこの10年間に我々が学んできた中で最も重要なことなのだ。それほど重要だからこそ、私の最後の主張として書くに値するのだ。だから何か1つだけ覚えておくとしたら、このことを覚えておいてほしい。

「バージョン」の代わりに「変更」を管理するなら、マージはずっとうまく機能し、組織的な目的が求めるときにはいつでもブランチすることができ、それというのもマージするのはお茶の子だからだ。

Subversionユーザからこんな話を聞かされたことが何度あったかわからない。「コードをブランチしようと思って、それはうまくいったんだけど、マージする段になったら、もうまったくの悪夢で、すべての変更を1つひとつ手で再び当て直さなきゃならなかった。こんなこと2度とやるものかと誓って、ブランチの代わりにif文を使う新しい手法を開発したんだ」

時には彼らが自分の開発したトランク1つのやり方を誇りに思っていることさえある。自分の使っているバージョン管理ツールが本来果たすべき役割を果たさない問題を回避したのが美徳でもあるかのように。

分散バージョン管理では、マージは簡単で、うまく機能する。だから安定版ブランチと開発版ブランチを作ったり、あるいはデプロイ前にQAチームがテストするための長期間存続するブランチを作ったり、ちょっと新しいアイデアを試して具合を見るための短期的なブランチを作ったりすることができる。

これは見落としてしまうにはあまりに重要だ。私がここで文章を書くようになってからの10年間に起きた、ソフトウェア開発技術における最大の進歩かもしれない。

言い方を変えると、Mercurialをあきらめるくらいなら私はC++に戻る方を選ぶ。 Subversionを使っているなら、やめることだ。すぐに。Subversion=ヒルで、MercurialとGit=抗生物質だ。より優れたテクノロジーが今や存在するのだ。

17hginit.png

とても多くの人がその新しいプログラムモデルをちゃんと理解せずにMercurialへと飛び込んでおり、そのために壊れているとか悪いものだと思ってしまうこともあるかもしれないので、私はMercurialのチュートリアルHgInitを書くことにした。

今では分散バージョン管理システムをdisったあのポッドキャストについて人に聞かれたら、あれは私の長年の友でありライバルであるエリック・シンクが入念に仕組んだ罠だったのだと答えることにしている。彼は非分散バージョン管理システムを作っているのだから。彼がバグトラッキングソフトを売り始めたときのように、お仕置きとして、Fog Creekのロゴ入りの高級なバックパックを、ニセの定型文の手紙をつけて送りつけてやった。FogBugzユーザ全員に標準的なクリスマスギフトとしてそんな高価なものを送っているくらい我々がうまくやっているのだと思わせるために。

さて、もう時間がなくなってきたようだ。この10年間、あなた方に私のエッセイを読んでいただいて、とても光栄に思っている。これ以上の読者達というのを考えることができない。あなたが40以上の言語へと記事を翻訳するために時間を割いてくれた何百というボランティアの1人であるにせよ、あるいは私宛てのメールを書くために時間を取ってくれた22,894人の1人であるにせよ、あるいはニュースレターを購読してくれた50,838人の1人か、私の書いた1067本の記事を読みにサイトを訪れる年に2,262,348人いる中の1人であるにせよ、私はあなたの向けてくれた関心に心から感謝している。


(オリジナル: Distributed Version Control is here to stay, baby)

戻る

Personal tools