Gitのススメ

1,978 views

Published on

Git 導入を提案するための資料になれば。
ターゲットは「形式上バージョン管理やらないと」と思っているマネージャー/CVSやSubversionを触ったことがある、もしくはまったく触ったことがない開発者の人達です。

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,978
On SlideShare
0
From Embeds
0
Number of Embeds
44
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gitのススメ

  1. 1. git のススメ ~ 共同開発というスタイル ~
  2. 2. git とは <ul><li>Linux カーネルのソースコード管理を目的として、リーナス・トーバルズ氏によって </li></ul><ul><li>開発された オープンソースの 分散型バージョン管理システム </li></ul><ul><li>現在のメンテナンス担当は濱野純( Junio C Hamano )氏 </li></ul><ul><li>大規模プロジェクトにおける処理の効率化に重点が置かれており、変更点の抽出や </li></ul><ul><li>リポジトリ操作が 高速かつスケーラブル になるよう記述されている </li></ul><ul><li>ブランチやマージを簡単、高速に利用することができる </li></ul><ul><li>CVS や Subversion が個々のファイルを処理の対象とし変更を管理していく </li></ul><ul><li>のに対し、 git では プロジェクト全体 を処理の対象とする </li></ul><ul><li>プロジェクトの変更履歴を可視化・ナビゲートするツールを同梱 </li></ul>
  3. 3. git 採用実績 Linux カーネル以外にも、以下の有名プロジェクトがバージョン管理システムに git を採用している <ul><li>X.org </li></ul><ul><li>Ruby on Rails </li></ul><ul><li>Perl </li></ul><ul><li>Samba </li></ul><ul><li>VLC </li></ul><ul><li>Yahoo! UI Library </li></ul><ul><li>Merb </li></ul><ul><li>Wine </li></ul><ul><li>DragonFly BSD </li></ul><ul><li>Android </li></ul>
  4. 4. 分散型バージョン管理システム  代表的なオープンソースのバージョン管理システムとして CSV や Subversion が 挙げられるが、これらは 集中型 のバージョン管理システムである [ 集中型バージョン管理システム ] リポジトリ(プロジェクト開始時から現時点までの変更を蓄積しているデータベース)が 中央にひとつだけあり、「以前の状態に戻る」や「変更の履歴を調査する」といった操作 はすべてそのリポジトリにアクセスして行われる 集中型バージョン管理システムを採用した場合、プロジェクトメンバーの 開発フローは以下のようになる <ul><li>共用リポジトリより、最新バージョンのプロジェクトをチェックアウト </li></ul><ul><li>チェックアウトしてきたファイルを変更 </li></ul><ul><li>(リポジトリの管理者に許可をとり)変更内容をコミット </li></ul>この時点で、変更内容は 中央リポジトリへ即座に 反映される!
  5. 5. 分散型バージョン管理システム  [ 集中型バージョン管理システムにおける課題 ] <ul><li>プロジェクトメンバーが増えれば増えるほど中央リポジトリ(を立てているサーバ)の </li></ul><ul><li>負荷が高くなる </li></ul><ul><li>対象のドキュメント数が増えると変更点の抽出やリポジトリ操作に時間がかかる </li></ul>[memo] :各ファイルを処理対象とし前リビジョンからの差分で変更を管理しているという性質によるものだから、集中型だからそうってわけじゃないのかな・・・ <ul><li>中央リポジトリへアクセスできない場合、ローカルでの変更作業を行うことができない </li></ul><ul><li>間違った変更に気づかずコミットしてしまった場合の影響が大きい </li></ul><ul><li>他のプロジェクトメンバーへ影響を及ぼす可能性のある変更をした場合、 </li></ul><ul><li>その変更をコミットすることへの精神的敷居が高い </li></ul>など...
  6. 6. 分散型バージョン管理システム  [ 分散型バージョン管理システム ] <ul><li>プロジェクトメンバーの一人一人がローカルにリポジトリのコピーを持ち、 </li></ul><ul><li>「以前の状態に戻る」「履歴を調査する」といった操作はそのローカルリポジトリ内で </li></ul><ul><li>完結する </li></ul><ul><li>コミット、ブランチの作成など、リポジトリへの操作はネットワーク接続を必要としない </li></ul><ul><li>コミットと変更履歴の公開(共用リポジトリとの同期)とが分離され独立した </li></ul><ul><li>操作になっている </li></ul>[ 開発フロー ] <ul><li>共用リポジトリより、リポジトリをローカルにコピー </li></ul><ul><li>ローカルリポジトリからワークツリーへ、あるリビジョンをチェックアウト後、ワークツリー上でファイルを編集し、ローカルリポジトリへコミット </li></ul><ul><li>必要ならローカルにブランチを切って変更、コミット </li></ul><ul><li>まとまった変更が完成した時点で共用リポジトリで変更履歴を </li></ul><ul><li>公開する </li></ul>この時点で初めて 変更内容が公開される!
  7. 7. 分散型バージョン管理システム  [ 集中型と分散型の比較(開発フロー) ] マシン1 共用 リポジトリ マシン2 ワークツリー 1.checkout 2.diff/ merge 3.commit [ 集中型 ] マシン1 共用 リポジトリ マシン2 ワークツリー [ 分散型 ] 共用 リポジトリ 2.checkout 3.diff 4.Commit 1.clone/pull 5.push 修正-> 3->4 を 繰り返す ある程度まとまった単位で共用リポジトリと同期
  8. 8. git 導入により変わること このような分散型バージョン管理システムが持つ特性に起因し、 git を導入した場合 以下のような利点が挙げられる <ul><li>移動中など、 ネットワークに接続できない場合でも ローカルリポジトリ内で </li></ul><ul><li>作業を進めることができる </li></ul><ul><li>他のプロジェクトメンバーへの悪影響を恐れず、実験的な変更を自由に行い </li></ul><ul><li>その途中経過を記録しておくことができる </li></ul>->  メンバーのモチベーションの向上、プロジェクト自身の クオリティ向上へつながる! <ul><li>まとまった変更が完成した時点でのメンバーへの公開となるため、集中型 </li></ul><ul><li>システム利用時のような コミットへの躊躇がない </li></ul>->  プロジェクト管理ツールと併用することで、コンフリクト発生率を 下げることも可能!
  9. 9. なぜ git なのか? <ul><li>Linux カーネルの開発で利用されているという実績 </li></ul><ul><li>数千人規模のプロジェクトでも利用可能なスケーラビリティ </li></ul><ul><li>圧倒的なパフォーマンス(高速性) </li></ul>->  ブランチ、マージを高速に行えることにより、ノンリニアな開発を 強力にサポートする! これらの特徴に 分散型バージョン管理システムの特性が加わることで・・ 「“共同開発” とは何なのか」を 身をもって感じることができる!!
  10. 10. 参照 <ul><li>Git --- http://git-scm.com/ </li></ul><ul><li>Git - Wikipedia --- http://ja.wikipedia.org/wiki/Git </li></ul><ul><li>Git 入門 --- WEB + DB PRESS vol.50 – p.50~93 </li></ul>

×