最近、ソースコードやドキュメントの管理に
分散バージョン管理ソフトを試してみています。
具体的には gitとMercurial(hg)を使ってみています。
■利点とか
それら分散バージョン管理ソフトを使ってみて感じた利点は以下の通り。
- 中央集権的でない使い方が可能
- サーバーにつながっていない時も使える（！！）
- 分散＝分散バックアップにもなる
- ブランチ(枝分かれ)が簡単
- 複数人でかなり作業がしやすそう
などがあると感じました。
■分散型の利点
以前使っていた、cvs や Subversionは、
中央集権型のため、
ひとつのリポジトリ（ソースコード置き場）に対して、
コミット（変更の反映）したりしていました。
例えばそのリポジトリはサーバーなんかに置いていました。
で、サーバーと繋がっていないと、
ちょっとした変更もコミット、反映できなくて困ったりしました。
（社内サーバーとかだとよくある）
ところが分散管理だと、
他のリポジトリから clone（リポジトリの複製）すると
まず手元にリポジトリそのものを持ってきます。
この時点ですでにバックアップにもなっています。
その後は、ソースを編集したら
手元のリポジトリにコミット（変更の反映）しつつ、
サーバーに push (リモートのリポジトリに反映)します。
手元でコミットするだけならサーバーはいりません！
つまり、会社を休んでスタバでプログラミングしつつ、その場でコミットしたりバージョン管理ができます！！
（マクドでも可）
素晴らしくないですか？
誰かがサーバー側に push した場合など、
サーバーに上がった変更を持ってくる時は pull します。
■ブランチ作業のしやすさ
また、これらの作業、つまり
リポジトリのclone、push、pullはサーバーがなくても手元のリポジトリ同士でもできます。
これを使うと簡単にブランチ(枝分かれ)が作れます。
例えば、サーバーから clone してきた、
もしくは pull してきたリポジトリとソース一式があります。
この手元のリポジトリは絶賛開発中なのですが、
クライアントや上からの要望でちょっとした変更を
試したいと思いました。
この時は、開発中のリポジトリとは別に
新機能用のディレクトリに cloneします。
新機能用リポジトリができますので、
それに新機能を足して編集してコミット。
あとは、新機能が実装できたら全部コミットして、
元の開発中のリポジトリに push します。
もし、新機能がいらないやと思ったら、
ディレクトリごとポイッと削除してしまえばいいです。
開発中のと新機能のと、
ソースコードの結合、衝突の回避(merge作業)など、
後の作業はあるのですが、
何がすごいかというと、これが全部サーバーなしで
手元で簡単に低コストでできてしまうことです。
これは分散バージョン管理を使わざるを得ないのではないか！？
と思った次第です。
■次回は……
さて、次回は、実際のソフトを使ってみた雑感をお伝えします。
その2 git編です。
■参考リンク
カテゴリ: [ 開発 ]
