日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

ソフトウェア開発履歴の改変例の分析に向けて
林 晋平

佐伯 元司

ソフトウェア構成管理において，開発者はしばしば，ソフトウェア開発履歴に記録される変更の理解性や利用性の向上を目的として，履歴の改変を行う．本稿では，履歴をより適した形に改変するための支援手法や自動化手法の開発を目指し，履歴改変の実例を収集・分析する試みについて述べる．

たりすることが知られている [5]．また，その検出・

1 はじめに解消手法が提案され，既存履歴に対する調査が行われソフトウェア構成管理において，開発者はソフトている．こういった試みを促進するためには，履歴改ウェアに対して行った変更をリポジトリに蓄え，他の変の実例の収集が重要である．

開発者と共有する．蓄えられた変更の記録はコミット

本稿では，版管理システム Git を用いて開発されと呼ばれ，版管理システムによってこれらが管理されたプロジェクトの開発履歴から履歴の改変の実例を収ている．コミットは開発者間で共有され，さまざまに集し，分析を行う試みについて述べる．

利用されるため，適切に構成することが望ましい．例
えば，我々は以下の理由によりコミットの粒度を適切に保ち，意図が混在した変更を構成しないことが望ましいとまとめている [3]．

2 履歴の改変
本稿では，文献 [2] で扱っている履歴リファクタリ
ングに従った履歴の改変を扱う．すなわち，変更列の再利用 混在した変更の一部を他のブランチに適用書き換えであって，一連の変更の前後における管理する際には，その一部の抽出が必要であるため．

対象のソフトウェア成果物の内容に書き換えの影響

破棄 混在した変更の一部を棄却する際には，同様が及ばないようなものを扱う．こういった履歴の改変にその一部を抽出する必要がある．
理解 コミットログに複数の意味が記述されると，それらと差分のどの部分が対応しているかが不明確になってしまう．

例は，履歴の変更内容を保った改変として有用と考える．
前述した履歴の改変は，版管理システム Git が管理するオブジェクトの状態としては，図 1 に示すよ

複数の意図が混在した変更は，もつれた変更（tan-うな場合として扱える．図において，各円はコミットgled change） [4] と呼ばれ，変更の理解において悪オブジェクトを，四角形はコミットが指すデータオブ影響を及ぼしたり，コミットを分析するソフトウェア

ジェクトを，コミットオブジェクト間に張られた矢印

リポジトリマイニング手法の結果に悪影響を及ぼしは派生元のコミットへの参照を表す．ここでは，共通∗ Towards Analyzing Rewriting of Revision History.

This is an unrefereed paper. Copyrights belong tothe Author(s).
Shinpei Hayashi, Saeki Motoshi, 東京工業大学大学院
情報理工学研究科計算工学専攻, Dept. of Computer
Science, Tokyo Institute of Technology.のコミット a から，2 つの変更列，a → b → c → dと a → e → f が派生している．ここで，コミット dと f は，いずれも共通のファイルツリーオブジェク
トを指しており，これは，コミット d と f が保持している成果物の内容が等価であることを意味する．こbe400
2000c# Instancesfd600tree

1101000

Lengtha
図2
図1100

分析結果

対応する部分変更列の例

ミットのオブジェクトが公開リポジトリから取得でれらの変更列は，共通の派生元コミットから同一の成きなかった 16847 対を除いた 19443 対を対象とした．

果物の内容へと遷移する，すなわち，同一の変更内容得られたコミットオブジェクトの対に対して，共通のを表しているため，一方を書き換えて他方を得た実例である可能性がある †1 ．

派生元コミットを特定し，それに至るまでの部分変更

現実には，履歴書き換えは開発者のローカルリポジ得られた部分変更列の長さの分析結果を図 2 に示

トリや少人数の開発者のみ注目する派生リポジトリ

す．図の横軸は変更列の長さ（対数スケール），縦軸で完結するかもしれない．その場合，書き換え元のコは観測された実例数を表しており，長さ 10000 以上

ミット（図 1 では，d と f のうち導入時刻が古い方）の変更列については省略している．列が長くなるほの取得が困難となる．開発者のローカルリポジトリ上ど観測数が少なくなっている．有益な履歴改変例は，の振る舞いを監視したり [6]，リポジトリの継続的な開発者が把握可能でかつ短かすぎないものに含まれマイニング [1] が必要になるかもしれない．

ると考えるが，公開リポジトリ上にも十分にそれらが列の長さを計測した．

含まれていることがわかる．今後，実際の部分履歴に3 公開リポジトリに対する予備調査含まれるコミットの内容や部分履歴間におけるコミッ

現実の版管理リポジトリからどれだけ前述の変更トの対応関係を調査することにより，より有用なデー列の対が得られるかを確かめるため，既存の公開リポタを構築していきたい．

ジトリからの抽出を試みた．German らが提供している Linux カーネルの開発リポジトリのデータベー

4 むすび

ス [1] に記載されているリポジトリ群のうち取得可能

本稿では，版管理システム Git を用いて開発されな 432 リポジトリを用意した．データベースはリポたプロジェクトの開発履歴から，履歴の改変の実例をジトリ群における各コミットの指すファイルツリーオ収集し，その分析を行う試みについて述べた．

ブジェクトのハッシュ値を保持しているため，同一リポジトリ内で同一のハッシュ値を持つ，異なるコミッ謝辞 本論文に対して様々なコメントを頂いた，東京工業大学の松田淳平氏に感謝する．

トオブジェクトを対象とした．簡単化のため，3 つ以上のコミットオブジェクトが同一のファイルツリー

参 考 文 献を指している場合は除外した．データベースからは，[1] German, D. M., Adams, B., and Hassan, A. E.: A
Dataset of the Activity of the Git Super-repositoryof Linux in 2012, Proc. IEEE/ACM 12th Working
Conference on Mining Software Repositories, 2015,
pp. 470–473.

36290 個のコミットの対が得られ，ここから，該当コ†1 もちろん，履歴の書き換え以外にも変更内容が共通となるコミットが生じる原因はある．

[2] Hayashi, S., Omori, T., Zenmyo, T., Maruyama,K., and Saeki, M.: Refactoring Edit History ofSource Code, Proceedings of the 28th IEEE International Conference on Software Maintenance, 2012,
pp. 617–620.
[3] Hayashi, S. and Saeki, M.: Recording Finergrained Software Evolution with IDE: An Annotationbased Approach, Proc. Joint ERCIM Workshop on
Software Evolution and International Workshop on
Principles of Software Evolution (IWPSE-EVOL2010), 2010, pp. 8–12.
[4] Herzig, K. and Zeller, A.: The Impact of Tan-gled Code Changes, Proc. 10th International Workshop on Mining Software Repositories (MSR 2013),
2013, pp. 121–130.
[5] Nguyen, H. A., Nguyen, A. T., and Nguyen,T.: Filtering Noise in Mixed-Purpose Fixing Commits to Improve Defect Prediction and Localization,
Proc. 24th IEEE International Symposium on Software Reliability Engineering (ISSRE 2013), 2013,
pp. 138–147.
[6] 松田淳平, 林晋平, 佐伯元司: 分散型版管理リポジト
リでの作業履歴記録ツールの試作, 電子情報通信学会技術研究報告, Vol. 115, No. 153(2015), pp. 45–50.