CVS (バージョン管理システム)やSubversionに代わるバージョン管理システムとして、Gitというシステムが注目されているらしい。Linuxのカーネル開発で使われるのが目的で作られたとのことですが、最近ではカーネルのみならずFedoraやGnomeなどのプロジェクトも利用しているそうな。
Gitについてはマイコミジャーナルでも取り上げられており、SubversionからGitに乗り換えたという人の評価が紹介されています。
Gitが便利なポイント
- 使うにあたって必ずしもリモートリポジトリを持っている必要がない。ローカルリポジトリで作業を開始し、それに対してコミットを実施できる。リモートにコミットする必要があるSubversionがとても重く感じられ、Gitはとても素早く感じられる。
- 変更した内容はまとめてほかのリポジトリに適用したり、ほかのリポジトリの変更内容をマージすることができる。マージがちゃんと実施されるか懸念していたが正確にうまく機能している。
- Gitにはコミットアクセスという概念がない。従来の方式ではメインとなるブランチがあり、そのコピーを各々の開発者が持つことになる。メインブランチへのアクセスは特定の人物に制限されており、権限を持たない開発者はバグシステムにパッチを登録するなりメールでパッチを提供するなどして取り込んでもらう必要がある。コピーされたリポジトリという方式は一貫性を保つのが大変。Gitではこうした問題がない。それぞれが自分のリポジトリを持っており、リポジトリごとにマージが実施される。
僕は仕事ではもっぱらSubversionを利用してるのですが、Gitの特徴である「分散型」ってデメリットになりはしないのかな?とふと思ってみた。というのは、上記で引用した「メインブランチへのアクセスは特定の人物に制限されており、権限を持たない開発者はバグシステムにパッチを登録するなりメールでパッチを提供するなどして取り込んでもらう必要がある。」が僕的にはメリットに感じるんですよね。要はコミットする権限を制限したいって場合も多々あると思うのですが、そこら辺の仕組みってGitではどうなっているんだろう?
あと、「それぞれが自分のリポジトリを持っており、リポジトリごとにマージが実施される。」って部分もちょっと気になる。それぞれが自分のリポジトリを持っていて、その自分専用のリポジトリごとにマージされる・・・。ヽ(´~`;)ウーン。なんかAさんとBさんが持っているリソースにギャップが出てくる気がしてならない。
でもまぁ、引用した意見って実際にSubversionからGitへ乗り換えた人が言っていることだから、そこら辺は不整合が出ないように上手く作られているのかな?
追記:@IT(Subversionとは一味違う「分散バージョン管理」とは?)で分散バージョン管理についての図解がありました。ちゃんとメインのリポジトリは存在しているんですね。疑問がすんなりと晴れました。
便利そうなので機会があったら使ってみようと思います。
追記:インストールと軽い動作確認をしてみました。
Eclipse用のプラグイン(EGit)もあるらしい(EclipseでGitを使おう! EGitを試してみる)ので、これも後日試してみたいと思います。
参考になりそうなサイト
関連するかもしれない記事
- バージョン管理 LinuxへのGitのインストールと軽い動作確認
- eclipseからSubversionのリポジトリに接続(subclipse)
- CentOS 5.5 skypeのインストール
- linuxへのSubversionのインストール
- Linux Wineのインストール
他のブログも読む



One Response
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Continuing the Discussion