Mercurialを使ってみて確信した

DVCSは仕事で使える。(・∀・）イイッ！

Mercurialはいけてる。(・∀・）イイッ！

きっとGitもいけてる。(・∀・）イイッ！

Mercurialがお勧めです。

SubversionもGitもまだ使っていないならなおさら。

1. 学習コストが低い*1
2. すぐ使えるWindowsクライアントがある
3. 小規模～パーソナルプロジェクトで取り扱いやすい
4. 開発の質があがる

学習コストの実際

Windowsクライアントがあるということはとても良いことです。インストールから基本的な開発操作の流れまで、３０分程度で済ますことができます。

開発者の日々の作業、update、commit、１日で覚えられます。pull、commit、diff、revert、log、mergeを覚え慣れるまで１周間もあれば充分でした。開発者たちは必要に応じて互いにpullしmergeするようになりました。

リポジトリとブランチの管理はメンバーの1人が覚えれば充分です。初めてということで私自身が担当していましたが、開発をとりまとめる人か、開発のボトルネックが分かる開発者に任せればよいという感じでした。

ブランチ戦術は少し悩みましたが、こちらのサイトが参考になりました。

見えないチカラ: A successful Git branching model を翻訳しました

あるプロジェクトのMercurial導入の軌跡 - 放牧日記

 プロジェクトのルールとして前もって決めておくことで、混乱もなく使えるようになります。逆に、前もって決められないプロジェクトはどうあがいても炎上する運命にあるということに気づきましたが、これは別の話で。

Windowsクライアント

tortoiseHgとHgワークベンチです。最初はワークベンチをどう使えばよいかわかりませんでした。ペインの多さにとまどい、最初に怯んでしまったことを告白しておきます。しかし、使い始めてすぐに理解しました、使いやすいようによく考えられている*2、と。

習うより慣れろです。書籍も出ているので記事の最後に載せておきます。

小規模プロジェクトで取り回す

大規模プロジェクトには不向きと感じました。ツールとしては当然大規模プロジェクトでも使えるのですが、組織ルールとしてSubversion（もしくは組織が長年使用しているもの）以外を選択できないケースが往々にしてあります。無理に使おうとすると、Subversion+Git/Mercurialといったハイブリッド構成の管理になります。ハイブリッド構成は構成管理の専任者をしっかり擁立しないと混乱の元になるため、組織の体制やプロジェクトの体力によっては困難です。

私は、実態としてハイブリッド構成*3で管理していましたが、混乱になるため開発者には存在を公開しないようにしていました。

逆に、小規模プロジェクトやプライベートプロジェクトには、「始めやすく」「覚えやすく」「使いやすい*4」の３拍子そろっているMercurialが、気持ち良いほどに馴染みます。

開発の質があがる

質は感覚です。品質が客観的にあがったという結果はありません*5。ただ、感覚として感じたということをここで正直に伝えたいです。

今まで、機能の単位、単体テストの単位、コミットの粒度が曖昧でした。自分の担当の開発の他に、重複する機能の開発、マージ後の不具合の調査と修正、を同時並行に扱っておりソースにはなんらか複数の意図がまぎれているのが常でした。これによって、コードレベルの流用、コードを参照しての再設計が難しい…つまり、一言でいうとスパゲティを量産していました。Subversionの履歴はきまぐれなタイムカードのようなものでした。

Mercurialを使いはじめ、日々のコミットを眺めていて気づいたのは、いま自分がスパゲティを作ったのかそうでないのか、履歴を汚したのかどうかが、目の前に見えているということでした。

(ﾟεﾟ)ｷﾆｼﾅｲ!!

(ﾟεﾟ)…

(；´д｀)気になる

本来、保守性のよいコード、綺麗な履歴というものはツールによってなされるものではなく、開発者の熟練度と心遣いによるものです。このように気づきを与え、また、改善に取り組みやすいという点を、ツールが開発者の成長を助けている＝質があがるとしました。

Git vs Mercurial で Mercurial を採用する理由

この半年Mercurialを使った感想です。

・Mercurialを覚えてからGitに移行してもよい*6

・Mercurialを覚えてからSubversionを覚えてもよい

内部の仕組みを覚えて、ブランチを綺麗に保ちながら使いこなせたらどれだけ素敵なことかと思います。今の時代、開発者はSubversionやGitを『使いこなせて当たり前』と言いたいところですが、現実はそうではありません。開発者が集まってみたら、初めて使う人、なんとなく使ってた人、ざらにいます。プログラムは数ヶ月、数年ぶりなんていう人もよくいます。私です。30歳と60ヶ月をゆうに過ぎた3流開発者もいます。私です。

このような人々（主に私）が、ある程度のコードの質を確保しつつ、忘れてしまうことも含めて、安定した開発をするには、学習コストの低さが重要な要素となってきます。

構成管理の初心者には迷わずMercurialを、ある程度の経験があるのならGitでよいでしょう。

 と、私が独断と偏見でMercurial(またはGit)を導入していく意義があると勝手に確信したことでした。

入門TortoiseHg + Mercurial

*1:Gitが学習しづらいというわけではありません。Mercurialのがより容易という感じです。

*2:印象には個人差があります

*3:同期タイミングがゆるいのでハイブリッドを名乗るのはおこがましいですが

*4:印象には（ry

*5:よ～く分析するとあるのかもしれませんが

*6:逆もしかり