Gitのススメ

git のススメ～共同開発というスタイル～

git とは

Linux カーネルのソースコード管理を目的として、リーナス・トーバルズ氏によって

開発されたオープンソースの分散型バージョン管理システム

現在のメンテナンス担当は濱野純（ Junio C Hamano ）氏

大規模プロジェクトにおける処理の効率化に重点が置かれており、変更点の抽出や

リポジトリ操作が高速かつスケーラブルになるよう記述されている

ブランチやマージを簡単、高速に利用することができる

CVS や Subversion が個々のファイルを処理の対象とし変更を管理していく

のに対し、 git ではプロジェクト全体を処理の対象とする

プロジェクトの変更履歴を可視化・ナビゲートするツールを同梱

git 採用実績 Linux カーネル以外にも、以下の有名プロジェクトがバージョン管理システムに git を採用している

X.org

Ruby on Rails

Perl

Samba

VLC

Yahoo! UI Library

Merb

Wine

DragonFly BSD

Android

分散型バージョン管理システム  代表的なオープンソースのバージョン管理システムとして CSV や Subversion が挙げられるが、これらは集中型のバージョン管理システムである [ 集中型バージョン管理システム ] リポジトリ（プロジェクト開始時から現時点までの変更を蓄積しているデータベース）が中央にひとつだけあり、「以前の状態に戻る」や「変更の履歴を調査する」といった操作はすべてそのリポジトリにアクセスして行われる集中型バージョン管理システムを採用した場合、プロジェクトメンバーの開発フローは以下のようになる

共用リポジトリより、最新バージョンのプロジェクトをチェックアウト

チェックアウトしてきたファイルを変更

（リポジトリの管理者に許可をとり）変更内容をコミット

この時点で、変更内容は中央リポジトリへ即座に反映される！

分散型バージョン管理システム  [ 集中型バージョン管理システムにおける課題 ]

プロジェクトメンバーが増えれば増えるほど中央リポジトリ（を立てているサーバ）の

負荷が高くなる

対象のドキュメント数が増えると変更点の抽出やリポジトリ操作に時間がかかる

[memo] ：各ファイルを処理対象とし前リビジョンからの差分で変更を管理しているという性質によるものだから、集中型だからそうってわけじゃないのかな・・・

中央リポジトリへアクセスできない場合、ローカルでの変更作業を行うことができない

間違った変更に気づかずコミットしてしまった場合の影響が大きい

他のプロジェクトメンバーへ影響を及ぼす可能性のある変更をした場合、

その変更をコミットすることへの精神的敷居が高い

など．．．

分散型バージョン管理システム  [ 分散型バージョン管理システム ]

プロジェクトメンバーの一人一人がローカルにリポジトリのコピーを持ち、

「以前の状態に戻る」「履歴を調査する」といった操作はそのローカルリポジトリ内で

完結する

コミット、ブランチの作成など、リポジトリへの操作はネットワーク接続を必要としない

コミットと変更履歴の公開（共用リポジトリとの同期）とが分離され独立した

操作になっている

[ 開発フロー ]

共用リポジトリより、リポジトリをローカルにコピー

ローカルリポジトリからワークツリーへ、あるリビジョンをチェックアウト後、ワークツリー上でファイルを編集し、ローカルリポジトリへコミット

必要ならローカルにブランチを切って変更、コミット

まとまった変更が完成した時点で共用リポジトリで変更履歴を

公開する

この時点で初めて変更内容が公開される！

分散型バージョン管理システム  [ 集中型と分散型の比較（開発フロー） ] マシン１共用リポジトリマシン２ワークツリー 1.checkout 2.diff/ merge 3.commit [ 集中型 ] マシン１共用リポジトリマシン２ワークツリー [ 分散型 ] 共用リポジトリ 2.checkout 3.diff 4.Commit 1.clone/pull 5.push 修正-> 3->4 を繰り返すある程度まとまった単位で共用リポジトリと同期

git 導入により変わることこのような分散型バージョン管理システムが持つ特性に起因し、 git を導入した場合以下のような利点が挙げられる