LoginSignup
70

More than 5 years have passed since last update.

posted at

updated at

Git、Mercurial、Subversion、Perforce、どれを使う?

ツールが苦手なことをさせるとユーザーが苦労するので苦手分野で判断するといいと思う。

Gitは巨大なバイナリファイルが致命的に苦手だ。DVCSなのも災いしてリポジトリが膨れ上がるので映像関係の人とかはGitは避けるのが無難。

Mercurial(Hg)もDVCSだがHgの場合はファイルを--largeを指定して追加することでそのファイルだけ集中型扱いできるので巨大なバイナリも扱える。バイナリはマージできないのでロックベースで管理するしかないが拡張機能で一応ロックもできるようだし(ロックしないでITSのチケットで同じファイルを触らないように管理するほうがいいと思うけど)。

svnとP4は集中型なのでソースコードを扱う能力はDVCSであるGitやHgよりかなり劣る。ソースコードだけを扱うならこの2つよりはGitやHgの方がいい。ただP4のマージツールはよくできている(見やすい)。VCSにP4を使わない場合でもオススメだ。

GitとHgはツリーを一部だけを作業領域として取り出す操作ができないので、そんな必要がある場合はリポジトリを分割して設計して、それらをsubmodule(Git)、subtreemerge(Git)、subrepository(Hg)などの機能で統合管理する必要がある。というようにGitやHgはツリーの一部だけを扱うのはあまり得意ではない。

とりあえず、

  • 大きなバイナリファイルも扱うならsvn、P4、Hg。
  • 巨大なデータを扱うならsvn、P4。
  • ソースを扱うならGit、Hg。
  • ツリーの一部を扱うならsvnやP4がいいが、GitやHgでもできないことはない。
  • HgはサブリポジトリにHgだけでなくSVNやGitのリポジトリを使えるのでそういう使い方をする場合はHg一択。
  • Gitのブランチは先頭へのポインタであってブランチ自体を認識しているわけではないのでGitをサブリポジトリ/サブモジュールとして使うとupdate/checkoutしたときに「生首(detached head)」状態になってしまう。Gitリポジトリをサブリポジトリ/サブモジュールで使うのはいまいち。

...てなところ。Hgが万能だがdepth指定できるsvnもそれが必要なくらい巨大なリポジトリを扱うなら結構強い。どれか一つだけを選ばなくていいのならデータをsvnに、ソースをHgに置き、Hgのサブリポジトリとしてsvnのビルドに必要な部分だけを取り出すのが万能だろう。

それとここで出てないVCSについて私は使ったことがないので判断材料には含まれていないことを断っておく。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
70