Agileツール適合化分科会（変更管理・バージョン管理）

1
Copyright (C) Masanori KataokaAll Rights Reserved.
ソフトウェア変更歴管理・バージョン管理ツール
２０１４年８月２２日
片岡雅憲
2014/8/27
アジャイルツール適合化分科会（第１回）資料

2
＜内容＞
１．ソフトウェア構成管理技術とは
２．変更歴管理、そしてバージョン管理
３．Subversion
４．Gitと分散バージョン管理
＜参考文献＞

3
ソフトウェア構成管理技術は、ソフトウェアの開発に必要とされるリソースを統合的に管理する技術である。
この技術は、次の技術から構成され、発展してきた。
１）ソフトウェアリソースを開発チームのメンバー間で共有し、その
変更履歴を管理する技術。また、この変更履歴とバージョンとの
関係を管理する技術。
２）ソフトウェアの開発プロセスおよびビルド（作成）プロセス、デプロイ
（提供）プロセスを自動化する技術。また、これらプロセス間を
POM(Project ObjectModel)モデルに基づき相互接続し、ワーク
フロー化する技術。
３）上記ワークフローを反復型プロセスに発展させ、その自動化を含
めて総合的に改善するCI(Continuous Integration)および
CD(Continuous Delivery)技術。

4
2.1変更歴管理の重要性
ソフトウェアは、その開発の過程においても、また、運用・保守の段階に入っても、頻繁に変更される。この変更を記録し、過去を復元するために変更歴管理は重要である。
１）失敗に気付いた場合に（不良を検出した場合を含む）、失敗を検討・
修正するための過去の状態に戻れる。いわば、タイムマシンであり、
過去のいかなる時点にも戻れる。
２）同一のコードに対して、複数の開発者が、管理された方法で並行
アクセスし、チームによる共同開発が出来る。
３）既にリリースされたコードを保守しながら、最新のコードの開発を
並行して進めることが出来る。
４）変更の経時的な記録が残される。変更の理由、回数等の情報が
後で利用出来る。

5
2.2ソースコード変更歴管理からバージョン管理へ
ソースコード変更歴管理技術は、より論理的な単位を扱うバージョン管理技術へと発展していった。
１）ソースコードを個人の所有物としてではなく、開発チームメンバー
全員による共有リソースとして扱う。
２）単に断片的なソースコードの変更差分を扱うのではなくて、タグに
よりグループ化する。また、ソースコードの論理的時系列集合であ
るコードラインを管理するようにする。
３）コードラインおけるメインライン（トランク）とブランチとを設けて、
並行作業が出来るようにする。これにより、空間的、時間的に分散
したチーム間の協業を可能とする。
４）ソフトウェアのリリースにあたり、ブランチを使ってリリースし、メイ
ンラインは開発を継続できるようにする。
５）ブランチの変更は、テスト完了後に、メインラインの変更へマージ
する。

6
2.3バージョン管理上の留意事項
１）出来るだけ頻繁にチェックイン（Commit)する（１～数回/日）。これに
より、失敗した時に着実に回復出来る。
２）基本的にメインラインにチェックインする。ブランチにチェックインした
場合は後で、再度メインラインにチェックイン（マージ）することになる。
後者の方法は、CI(ContinuousIntegration)の考え方と相容れない。
３）チェックインのメタデータ（変更理由の説明等）を、分かり易く記述す
る。不良修正等については、これがなおざりになりがちなので注意が
必要である。
４）あらゆるリソース、およびそれに関する情報をバージョン管理下に
おき、旧バージョンが環境も含めて確実に再現出来るようにする。
５）リリースをする場合に、ブランチを作成して、そのブランチ上でリリー
スする。リリースしたものの不良はブランチ上で修正する。そしてまた、
メインライン上にも修正をフィードバックする。

7
2.3バージョン管理上の留意事項（続き）
６）大規模な機能の追加や変更を行う場合に、ともすると、メインライン
に迷惑をかけたくないとの理由でブランチを作りたくなる。しかし、
現実にはブランチを作ることは容易でも、これをメインラインにマージ
するのには大変な苦労が伴う。大規模な追加、変更であってもメイン
ライン上でコツコツと着実に進めた方が結局は早道である。
７）ブランチ上でリファクタリングを行った場合には、このブランチを
メインラインにマージするのに苦労することが多い。

8
2.4 バージョン管理システムの歴史
バージョン管理システム発展の歴史を、次に概説する。
１）SCCS(Source Code Control System)：
１９７２年にIBMSystem/３７０上にベル研Marc J.Rochkindが
開発、その後、ＵＮＩＸ上に移植される。バージョン管理システムの
元祖とも言うべきツール。
２）RCS(Revision Control System):
パデュー大学で１９８０年代に開発、その後、GNUソフトに組み
入れられた。複数ユーザは扱えない。
３）CVS(Concurrent Version System):
RCSをベースに、①クライアントサーバ機能②ブランチ、タグ機能
等を強化した。ネットワーク上で複数ユーザを扱うことが出来る。
Dick Gruneが開発し、１９８６年にオープン化、１９８８年に
B. BerlinerがC環境に移植した。

9
2.4 バージョン管理システムの歴史（続き）
４）Subversion:
CVSの問題点を解決するものとして、K. Fogel, BenCollins-
Sussman他により開発され、２００１年に公開された。彼らは、CVS
に精通しており、コマンドはCVSに合わせてあることから、CVSを置
き換えて急速に普及した。
RCS, CVSでは、管理の基本単位がファイルになっていて、これ
が処理時間の長さや、排他制御機能の限界の要因になっている。
Subversionは、管理単位をリビジョン（変更差分）としており、このよ
うな課題を克服している。
Subversionは、集中管理方式の開発では、優れたものになって
いて、現在最も多く使われている。しかし、分散型開発のバージョン
管理では限界がある。これには、Git等の分散型バージョン管理
システムが必要である（Gitについては後述）。

10
2.4 バージョン管理システムの歴史（続き）
５）Git:
Linuxカーネルの開発においては、分散バージョン管理ツールで
あるBitKeeper が使われていた。BitKeeperは、商用ツールであった
が、無料版も配布していて、これを使っていた。しかし、２００５年春に
無料版の条件を厳しくしたために、Linuxでは継続使用が不可能に
なった。
BitKeeperの代替品を探したが適切なものがなく、Linuxプロジェクト
のリーダーであるLinus Torvaldsと同僚の濱野純の２人が中心となっ
て、Gitの開発を始めた。開発開始後、３か月経った２００５年７月には、
当初バージョンが開発、公開され、その後、オープンソフトウェア
コミュニティの中で急速、かつ着実に改良が加えられ、ユーザ数を
増やしていった。

11
3.1 Subversionの長所
RCS, CVSにはないSubversionの長所は次のとおり。
１）ソースコードだけでなく、いかなるファイル、ディレクトリ、オブジェク
トファイル、メタデータも管理出来る。
２）ファイル、ディレクトリの追加、削除、コピー、名称変更が可能。
３）クライアントサーバ方式、ネットワーク対応、複数人でのファイル
共有が可能。変更において、アトミックなコミットにより、排他制御が
出来る。
４）差分管理が可能である。転送、格納にてデータが圧縮されていて、
性能に優れている。
５）ブランチ、タグの作成、マージが軽快である（性能に優れている）。
６）広範囲のプラットフォームをサポートしている。
３．Subversion

12
３．Subversion
3.2 Subversionによるバージョン管理の方法
Subversionにおいては、全てのリソースをリポジトリで集中管理
する。
１）リポジトリの内容に操作を加える場合は、リポジトリから各作業者の
作業領域に必要な部分をコピーする。これをチェックアウト(Check
out)と呼ぶ。そして、この作業領域において必要な変更・追加等の
操作を加える。
２）テスト等による確認の後、上記を正式のものとして、リポジトリに
反映して保存する場合は、コミット(Commit)する（チェックイン
（Check in)と言う場合もある）。
３）このように、作業領域での操作と、リポジトリへの正式なコミットを
分けることにより、リポジトリを複数の開発者間で共有することを可能
とする。これにより、高い品質を維持することが出来る。

13
３．Subversion
3.3 Subversionにおけるリビジョン番号の付与方法
１）RCS, CVSでは、ファイル単位に固有の番号付けが行われている。
すなわち、そのファイルが変更される度に番号が上がる。従って、
番号はそのファイルの変更回数を表す。
２）Subversionでは、リポジトリ全体に対するリビジョン番号が付けられ
る。したがって、プロジェクトの何かが変更されれば、リビジョン番号
は更新され、変更されていないモジュールのリビジョン番号も更新
されることになる。
３）このリビジョンを指定することにより、ある時点でのプロジェクトの
すべてのソースコードを正確に入手できる。
４）一方、このように自動的に付与されたリビジョン番号はとても覚え
にくい。そのような場合は分かりやすいタグを付与することが出来る。

14
３．Subversion
3.4 ブランチとタグ
１）Subversionのディレクトリには、①トランク、②タグ、③ブランチ
の３つのサブディレクトリがある。トランクは、開発のためのメインライ
ンのコードである。
２）タグは、特定のリビジョンにタグ名称を付けたものである。リビジョン
番号は、Subversionが自動的に付与したもので憶えにくいが、タグ
は開発者にとって意味のある覚え易い名称とすることが出来る。タグ
は、読み取り専用であることが一般的であるが、それだけでなく、これ
を更新していくことも出来て、次に述べるブランチと同じような扱いが
出来る。
３）ブランチはトランクから分岐させたもので、一般には、主たる開発を
トランクで継続的に行い、ブランチではリリースしたバージョンの保守
等を行う。

15
３．Subversion
3.4 ブランチとタグ（続き）
４）ブランチとしては、次のものがある。
①リリースブランチ：リリースしたものの保守
②リリース準備ブランチ：リリース準備作業が大きい場合
③ベンダーブランチ：第３者のソースをトランクと別に管理
④タスクブランチ：メインへ大影響を及ぼす変更に対応
⑤トピックブランチ：分散開発においてチケット対応の開発を行う

16
３．Subversion
3.5 Subversionにおけるロック方式
ソースコードの同じ個所を二人が同時アクセスして更新すると、
競合が生じてコードの内容が不正なものになる可能性がある。競合
を防ぐためのロック方式として次がある。
A.厳格なロック(strict lock)
B. 楽観的ロック(optimistic lock)
上記A.の方式では、誰かがチェックアウトするとこの人がチェックイン
（コミット）するまで、ファイル全体にロックが掛けられて読み取り専用
になり、更新出来ない。
一方、B.の方式では、複数人がチェックアウト出来るが、誰かが
チェックインした場合は、その更新内容を再度とり込んで、その上に
自分の変更分を加えてチェックインする。
Subversionは、B.の楽観的ロック方式を採用している。

17
３．Subversion
3.6 Subversionにおけるプロジェクトの作成
Subversionでは、ソフトウェア資産をプロジェクト単位に管理し、その概要は次の通りである。（参考文献４））
１）プロジェクトとは何か
プロジェクトと呼ばれるものの中には、一人で１～２週間で作り上げ
てしまうものや、数百人で２～３年を掛けるものまで多様なものが
あるが、基本的に次の特性を備えている。
a) プロジェクトは名称を持っている。独立した実体として識別される
ものである。
b) プロジェクトは業務目標を持っている。この目標達成のためにプロ
ジェクトの構成要素は連携し、結合する。
c) プロジェクトは一つのまとまりとして保守され、その一つのバージョ
ンがまとまった形でリリースされる。
d) プロジェクトの素材は共通の技術標準とガイドラインを共有し、
共通のアーキテクチャを使う。

18
３．Subversion
3.6 Subversionにおけるプロジェクトの作成（続き）
２）プロジェクトの構造
Subversion配下で作るプロジェクトの構造の例を、図3.1に示す。
その概要は下記の通りである。
a) サブディレクトリとして、①トランク、②タグ、③ブランチがある。
（3.4 を参照）
b) 最上位のファイルとして次がある。
－README:このプロジェクトについての簡単な説明
－BUILDING:このプロジェクトを再構築するための説明
－GLOSSARY:このプロジェクトで使われる専門用語

19
３．Subversion
3.6 Subversionにおけるプロジェクトの作成（続き）
２）プロジェクトの構造（続き）
c) 最上位のディレクトリとして、下記がある。
ーdoc/プロジェクトに関連するドキュメントを格納する
－data/ プロジェクトに関連するデータを格納する
－db/ プロジェクトでデータを扱う場合に、全ての
スキーマ関連の要素をここに格納する
－src/ プロジェクトのソースコードを格納する
－util/ プロジェクト固有のユーティリティプログラム、
ツール、スクリプトを格納する
－vendor/ サードパーティ製のライブラリ（バイナリ）等を
使う場合は、ここに格納する
－vendorsrc/ 上記のソースコードを格納する

20
３．Subversion
Sample/
tags/
trunk/
README
BUILDING
GLOSSARY
branches/
doc/
src/
build.xml
util/
vendor/
vendorsrc/
client/
A.java
B.java
server/
Y.java
Z.java
lib/
junit.jar
spring.jar
junit/
spring
図3.1Sampleプロジェクトの構造（参考文献４））

21
３．Subversion
3.7Subversionにおけるコードの共有
組織内外の他のプロジェクトとコードを共有したくなることがある。 Subversionでは、コードの共有手段として次の３つを用意している。
１）上位プロジェクトによるコードの共有
共有するべきコードを上位プロジェクト配下に置き、開発者はこれを
自分の作業領域にチェックアウトする。数が多くなると管理が煩雑に
なる。
２）外部項目（externals)によるコードの共有
externals属性を使うと別のディレクトリの内容を自分の作業コピー
に取り込める。チェックアウト時にリストを指定することにより自動的
に取り込める。
３）サードパーティ製のコードの取り込み
vendorsrc/ 配下に置くことにとってとり込むことが出来る。

22
4.1 Gitの概要
Gitは、Linuxのソースコード管理を目的として、Linuxの開発リーダであるLinus Torvaldsとその同僚である濱野純により開発された。
分散型バージョン管理システムであるのが特徴である。分散環境での変更管理はローカルなリポジトリを使って行われる（リモートのセントラル・リポジトリにアクセスしないで行われる）。
データの圧縮に工夫をしていて、Subversionに比較して動作性能が格段に優れている。

23
4.2 Gitの特徴
Gitの特徴として次があげられる。
１）分散開発を容易にする。中央リポジトリと同期をしていなくても、
分散リポジトリで独立して、並行開発が出来る。
２）何千人もの開発者を扱える。
３）高速で効率良く動作する。データ容量を節約して、転送時間を短縮
するための、データ圧縮技術、差分管理技術が優れている。
４）SHA1という暗号学的ハッシュ関数を用いて、全てのオブジェクトの
IDをユニーク化して、完全性や信頼性を維持している。
５）分岐して、分散開発した後の、マージ処理を容易に行うための機能
を備えている。

24
4.3 分散バージョン管理の仕組み
1）分散リポジトリ
Subversion等の従来型のバージョン管理システムでは、集中型
リポジトリにより、すべてのデータをセンタに集中管理して、これを
ネットワーク等を経由して共有させる。
Gitでは、ユーザ各人が専用のローカルリポジトリを持つ。ユーザは、
センターとのネットワーク接続が切断された状態であっても、ローカル
な作業は継続できる。そして、必要な時にセンターリポジトリにコミット
して同期を取る。
２）何を格納するか
Gitでは、ソースコードだけでなく、そのプロジェクトで必要とされる
あらゆるリソースを格納し、バージョン管理する。

25
4.3 分散バージョン管理の仕組み（続き）
３）ワークツリー(Work Tree)
Gitでは、リポジトリがセンターにあるのではなく、各ユーザーのロー
カルマシン上に作られる。このローカルなリポジトリをワークツリーと
呼ぶ。ワークツリーには、インデックスとファイルの両方が含まれてい
る。
変更・追加の作業はこのワークツリーの上で行われる。これを
「ステージされた変更」と呼ぶ。このステージされた変更を重ね、妥当
性を検証した後に、正式な変更として、ログメッセージを付けて
“commit” する。このように、Gitでの変更は2段階に分けられている。
“commit”することにより、新しいリビジョンが作られ、これがログメッ
セージと共に保存される。

26
4.3 分散バージョン管理の仕組み（続き）
４）上位リポジトリとの同期
分散管理をしているために、必要に応じて上位のリポジトリに自分
の変更を反映する必要があり、これは”push”により行われる。
また、逆に上位のリポジトリの変更を取り込む必要があり、これ
は、”fetch”で行われ、取り込んだ変更と自分の変更とを”merge”す
る。”pull”により、”fetch”と”merge”を同時に行うことが出来る。
５）タグとブランチ
プロジェクトがあるマイルストーンに達した時に、その時のリポジトリ
の状態に対して分かりやすいタグをつけられる。
また、分岐をした時はそれにブランチ名を付けられる。

27
4.4 Gitの内部構造
Gitの内部構造は次のようになっている。（参考文献５））
１）Gitのオブジェクト：次の4種類から構成される。
a)ブロブ(blob): binary large objectを意味し、データ実体が含まれて
いて、メタデータ（名前も）は含まれていない。
b)ツリー(tree):1階層分のディレクトリ情報を持つ。その配下の
全ファイルのブロブID、パス名、また、再帰的に参照する他の
ツリー名を含んでいる。
c)コミット(commit):リポジトリに加えられた各変更のメタデータを
保持する。具体的には、作者、コミッター、コミット日付、ログメッセー
ジ、コミットが実行された時のツリーオブジェクトを記録している。
d)タグ(tag):特定のコミットオブジェクトに対して、人が読める分かり
やすい名前を付けるための情報を含む。

28
4.4 Gitの内部構造（続き）
２) Gitオブジェクトの相互関係
作成者
Jon L
ツリー
8675309
ブロブ dead23、
ブロブ
feeble
V1.0
master
タグ
2504624
コミット
1492
ブランチ名
ブロブ
dead23
ブロブ
feeble
ツリー
8675309
図4.1 Gitオブジェクトの相互関係（参考文献５））

29
4.5 GitとSubversionの連携
現状において、Gitには勢いがあり、急速にユーザ数を伸ばしている。元々、Gitは、分散開発を目的として開発されたものでありSubversion の後継として開発されたものではないが、今や、Subversionの競合ツールとみなされている。
とはいうものの、いまだ、Subversionのユーザ数は圧倒的な多数を占めている。SubversionとGitとの相互関係として、次が可能であり、そのためのツールが用意されている。
１）Subversionのデータを全てGitに変換する。
２）Subversionのデータをそのまま活用し、そこから必要とされる変更
差分だけをGitに取り込む。また、逆に、Gitでの変更差分Subversion
に戻す。

30
4.6 GitHubサービス
GitHubは、Gitを利用するプロジェクトのためのホスティングサービスである。GitHubは、Logical Awesome社が運営しており、2008年からサービスが開始された。
GitHubを利用すれば、設備の準備に気を使うことなく、グローバルな分散開発が出来る。このために、Eclipse等の多くのOSSプロジェクトがGitHubに移行していて、現状ではOSSプロジェクトの半数をを超えているという。OSSプロジェクトは、GitHubを無料で利用出来る。
また、一般企業でのソフトウェア開発もオフショア、グローバル分散開発が進んでおり、GitHubの活用は更に進展していくものと考えられる。
Gitは、コマンドベースのツールであるが、GitHubでは、Gitインタフェースを内部に隠ぺいし、全てをWebインタフェースで利用できるようにしている。

31
4.7 Gerrit
Gerritは、Googleが開発したGit用ソースコードレビューツールである。
Android上のAp開発者を中心に普及しつつある。
Gerritの主要な機能は次の通りである。
①Gitを用いたソースコード変更の変更差分を分かり易い形式で
表示する。
②この変更差分の妥当性を自分でテストするだけでなく、パート
ナーにも転送して、レビューを受ける。
③CI(Continuous Integration)ツールと連動する。具体的には、
自分自身でのテストとパートナーによるレビュー完了したものだけ
をＪｅｎｋｉｎｓなどのCI ツールに渡して、メインファイルと統合する。
Gerritを日常作業の中に取り込むことにより、ソースコード更新の信頼性が大きく改善されると評判になっている。

32
1)“Continuous Integration” P. M. Duvall, S. M. Matyas, A. Glover
2007 by Pearson Education, Inc. 「継続的インテグレーション入門」（訳）大塚庸司、丸山大輔、岡本裕二、亀村圭助２００９年日系ＢＰ社
2) “Continuous Delivery: reliable software releases through build,testand deployment automation” JezHumble, David Farley 2010 Addison-Wesley
3)“Version Control with Subversion Second Edition” C. Michael Pilato, Ben Collins-Sussman, Brian W. Fitzpatrick 2009 O’Reilly
「実用Subversion 第２版」宮本久二男（監訳）、朝枝雅子、浜本階生（訳）
２００９年オライリージャパン
4)“Pragmatic Version Control Using Subversion 2ndEdition” Mike Mason 2006
「Subversion実践入門：達人プログラマに学ぶバージョン管理第２版」
でびあんぐる（監訳）２０１１年オーム社
5)“Version Control with Git” Jon Loeliger2009 O’Reilly 「実用Git」吉藤英明
（監訳）、本間雅洋、渡邊健太郎、浜本階生（訳）２０１０年オライリージャパン
6)「入門Git」濱野純（著）２００９年秀和システム
7)“Pragmatic Version Control Using Git” Travis Swicegood2008
「入門git」でびあんぐる（監訳）２００９年オーム社
＜以上＞

Agileツール適合化分科会（変更管理・バージョン管理）

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

Similar to Agileツール適合化分科会（変更管理・バージョン管理）

Similar to Agileツール適合化分科会（変更管理・バージョン管理） (20)

More from masanori kataoka

More from masanori kataoka (14)

Agileツール適合化分科会（変更管理・バージョン管理）