社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

バージョン管理システムにおけるスプリットコミットの調査およびその検出手法の提案
有馬諒†

肥後 芳樹†

楠本 真二†† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{r-arima,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし バージョン管理システムにおいて各コミットは 1 つのタスクからなるべきだと言われているが，1 つのコ
ミットに複数のタスクが含まれているものや，1 つのタスクが複数のコミットに分割されているものも存在する．本
研究では後者のコミットをスプリットコミットと呼ぶ．本研究ではまずどのようなスプリットコミットがリポジト
リに含まれているかを調査し，見つかったスプリットコミットを分割されたタスクの大きさによる 3 つのレベルに分類した．次にスプリットコミットの自動検出手法としてメソッドを頂点としたグラフを構築し，このグラフ上での変更されたメソッド間の距離を利用する手法を提案した．2 つのオープンソースソフトウェアのリポジトリに提案手法を適用した実験では適合率 0.8，F 値 0.7 の性能を示し，提案手法がスプリットコミットの検出に有効である
ことを示した．
キーワード

バージョン管理システム，スプリットコミット

1. ま え が き

コミットを変更の目的によって分類し，どのような目的の際に大規模なコミットが生じるかについて調査されている．しバージョン管理システムとはファイルの変更履歴を管理すかしこれらの研究では，1 つのタスクが複数のコミットに分割るシステムであり，ソフトウェア開発においてもソースコー

されているものについては扱われていない．本研究ではこのドなどの管理に利用されている．代表的なバージョン管理シ

ようなコミットをスプリットコミットと呼ぶ．

ステムとしては CVS，Subversion，Git などがある．これらのバージョン管理システムでは，変更履歴をコミットと呼ばれスプリットコミットの問題点として以下のものが考えられる．

る単位ごとに管理しており，各コミットは変更内容，日時，変リポジトリ分析性能の低下：ソフトウェア中のあるモジュー

更者，コメントなどから構成される．また，蓄積された変更履

ルを変更した際に，そのモジュールと同時に変更されるべき歴全体はリポジトリと呼ばれ，複数のコミットから構成され別のモジュールが存在する場合がある．そのようなモジューる．バージョン管理システムを用いることによって，あるコル間の論理的な結びつきはロジカルカップリング [6] [7] と呼ばミットが作成された時点でのファイルの内容やそのコミットれており，修正漏れの検知への利用が研究されている [8]．コでの変更内容を簡単に取り出すことができる．

ミットの変更内容からロジカルカップリングを求める際にス

1 つのコミットにどれだけの変更内容を含めるべきかという問題がある．Git 公式ドキュメント [1] ではコミットの単位がプリットコミットが存在すると，本来検出されるべき結びつきが検出されなくなる可能性がある．

論理的に独立した変更になるべきであると述べられており，1

コミット履歴の可読性の低下：ソースコードの変更内容やつの機能追加やバグ修正の変更ごとに 1 つのコミットとすべ

変更者，コメントなどがコミットには含まれており，コミット

きであると考えられる．そのような変更内容のまとまりを本

履歴をたどると誰がどのような意図をもって変更を加えたの研究ではタスクと呼ぶ．文献 [2] では単一のタスクごとに 1 つかを知るのに役に立つ．しかし 1 つのタスクが複数のコミッのコミットとするタスクレベルコミットという考えが紹介さ

トに分割されている場合，コミット履歴の可読性が低下しコれている．

ミット履歴を用いた変更内容の理解が難しくなる．

複数のタスクを含む大規模なコミットがリポジトリ分析の性能に悪影響を及ぼすことが明らかになっており [3]，このよ
うな大規模なコミットを複数のコミットに分割する手法について研究がなされている [3] [4]．また，文献 [5] では大規模な本研究の目的は以下の 2 つである．
• リポジトリにどのようなスプリットコミットがどの程度含まれているか調査する．
• スプリットコミットの検出手法を提案する．
—1—

以降，2 章ではスプリットコミットの予備調査について述べる．3 章では予備調査の結果に基づくスプリットコミットの 3

Ver. 1 commits

Ver. 2 commits

Ver. 3 commits

つの分類について述べる．4 章ではメソッドを頂点としたグラ
c1

フからスプリットコミットを検出する方法を提案する．5 章では提案手法の評価実験について述べる．6 章では妥当性の脅威

c2

Ver. 1 releasec3

c4Ver. 2 releaseについて述べ，最後に 7 章で本研究のまとめと今後の課題について述べる．

図 1 スプリットコミットの対象とするコミットの組

2. 予 備 調 査
まず初めに，実際のソフトウェアのリポジトリ中にはどのようなスプリットコミットが含まれているかについて目視による調査を行った．
2. 1

オープンソースソフトウェアのリポジトリを調査対象とした．
調査対象の詳細を表 1 に示す．
まず調査対象の期間にあるコミットについて，各コミットに含まれるタスクを変更内容やコミットのコメントなどから特定した．この結果を用いて同じタスクや関連するタスクを含むコミットの組を見つけ出し，これをスプリットコミットとした．見つかったスプリットコミットについてそれぞれのコミットでの変更の場所や内容，種類（機能追加，バグ修正，
コメント追加など）にどのような関係があるか調査した．2 つのリポジトリの調査には約 2 週間を要した．
結ジトリから発見した．発見されたスプリットコミットは以下の特徴によって分類することができた．
• それぞれのコミットで同じメソッドを変更しているス
プリットコミット．
• それぞれのコミットで呼び出し関係や継承関係にある
メソッドを変更しているスプリットコミット．
• それぞれのコミットで同じクラスで定義されたメソッドを変更しているスプリットコミット．

トであることを以下のように定義する（ 1 ） c1 ，c2 が同じバージョンの開発にかかわるコミット
である．
（ 2 ） c1 ，c2 はどちらともマージコミットではない．
（ 3 ） c1 の方が c2 よりも古いコミットである．
（ 4 ） c1 ，c2 の両方に同じタスクに関する変更が含まれて〜2011/06/07て，(c2 , c3 ) はスプリットコミットの可能性があるが，(c1 , c2 )はスプリットコミットの対象から除外する．
(2) は，マージコミットに含まれる変更内容は他のいくつかのコミットに含まれる変更内容を統合したものであるため対象から除外した．
(3) は，(c1 , c2 ) と (c2 , c1 ) のような重複した組が含まれないようにするために設定した．
(4) の条件において，どのような変更を同じタスクとしてみなすかによってスプリットコミットとなるコミットの組は大トの特徴をもとに決定した以下の 3 つのレベルでスプリット
コミットを分類する．
レベル 1：スニペットレベル
レベル 2：メソッドレベル
レベル 3：機能レベル
予備調査で見つかったスプリットコミットをこの 3 つのレベ
ルに分類した結果を表 2 に示す．
以降，3 つのレベルでのスプリットコミットの違いについて述べる．例として Apache Commons Collections [9] を用いた．

レベル 1：スニペットレベル
レベル 1 のスプリットコミットは，c2 での変更内容が c1 での変更漏れの追加や変更の取り消しなど c2 単独のコミットである必要がないものを指す．特徴としては，それぞれのコミッ
トでの変更箇所が同じメソッド内など，同一，もしくは非常に近い場所を編集していることである．我々は，このレベルのスプリットコミットをまとめて 1 つのコミットとすることでコミット履歴の可読性が向上すると考える．
Apache Commons Collections でのレベル 1 スプリットコ

表1 調査対象〜2001/07/15
2010/09/07

ましくないと考えたため，(1) の条件を設定した．図 1 におい

始まる行はそのコミットで削除された行を表す．

本研究では 2 つのコミットの組 (c1 , c2 ) がスプリットコミッ

対象期間
2001/04/15

る．本研究ではこのような影響を及ぼすコミットの統合は好図において+で始まる行はそのコミットで追加された行，-で

3. スプリットコミットの分類

Retrofitて 1 つのコミットとした場合，それらのバージョンのリリースきく異なる．そこで，予備調査で見つかったスプリットコミッ

果予備調査の結果，多くのスプリットコミットを 2 つのリポ

Apache異なるバージョンの開発にかかわる 2 つのコミットをまとめが行われたコミットでのソースコードの内容が変わる場合があ

調査方法

Apache Commons Collections [9] と，Retrofit [10] の 2 つの

2. 2

いる．

コミット数

追加行数

削除行数

55

15,401

2,055

45

7,370

2,303

表2

スプリットコミットの調査結果
Level-1

Level-2

Level-3

Apache13(0.9%)

21(1.4%)

49(3.3%)

Retrofit

4(1.7%)

9(3.9%)

32(14.0%)—2—

/*** Returns the values for the BeanMap.
** @return values for the BeanMap.
Modifications to this collection*
do not alter the underlying BeanMap.
*/
public Collection values() {ArrayList answer = new ArrayList( readMethods.
size() );for ( Iterator iter = valueIterator();iter.hasNext(); ) {answer.add( iter.next() );}return answer;+
return Collections.unmodifiableList(answer);}* Insert an element into queue.
** @param element the element to be inserted+*+* @exception ClassCastException if the specified<code>element</code>'s+* type prevents it from being compared to otheritems in the queue to+* determine its relative priority.
*/
void insert( Comparable element );+void insert( Object element );(a) 2002/03/19 13:34 のコミット(a) 2002/03/25 06:53 のコミット/*** Returns the values for the BeanMap.
*- * @return values for the BeanMap.
Modifications to this collection- *do not alter the underlying BeanMap.
+ * @return values for the BeanMap. The returnedcollection is not+ *modifiable.
*/
public Collection values() {ArrayList answer = new ArrayList( readMethods.
size() );for ( Iterator iter = valueIterator(); iter.
hasNext(); ) {answer.add( iter.next() );}return Collections.unmodifiableList(answer);
}

+

/**
* Insert an element into queue.
** @param element the element to be inserted*/
public synchronized void insert( final Comparable
element )public synchronized void insert( final Object
element ){m_priorityQueue.insert( element );}(b) 2002/03/19 22:19 のコミット

図 3 レベル 2 スプリットコミットの例
+
+
+
+
+
+
+
+

public void testListAdd() {List list = makeList();if(tryToAdd(list,"1")) {assert(list.contains("1"));if(tryToAdd(list,"2")) {assert(list.contains("1"));
assert(list.contains("2"));if(tryToAdd(list,"3")) {(b) 2002/03/25 07:00 のコミット(a) 2001/04/26 09:06 のコミット

図 2 レベル 1 スプリットコミットの例

ミットの例を図 2 に示す．(a) のコミットではメソッドの戻り
値を Read-only にする変更が行われているが，それに合わせたコメントの修正は (b) のコミットで行われている．
レベル 2：メソッドレベル
レベル 2 のスプリットコミットは，レベル 1 のスプリット

+
+
+
+
+
+
+
+

public void testListSetByIndexBoundsChecking2() {List list = makeList();tryToAdd(list,"element");
tryToAdd(list,"element2");

try {
list.set(Integer.MIN_VALUE,"a");fail("List.set should throw
IndexOutOfBoundsException [Integer.MIN_VALUE]");

コミットに加えて，c2 での変更が c1 での変更に依存している(b) 2001/05/05 01:34 のコミット

ものを指す．それぞれのコミットで変更されたメソッド間に

図 4 レベル 3 スプリットコミットの例

呼び出し関係や継承関係があることがが特徴である．このレベルのスプリットコミットをまとめることで，ロジカルカップ

Apache Commons Collections でのレベル 3 スプリットコ

リング [6] [7] などのリポジトリ分析性能の向上が期待できる．

ミットの例を図 4 に示す．(a) のコミットでは，TestList クラ

Apache Commons Collections でのレベル 2 スプリットコ

スにリストに対するテストケースを新たに追加している．(b)ミットの例を図 3 に示す．(a) のコミットではインターフェーのコミットでは，それとは別のテストケースを TestList クラ

ス中のメソッドの引数が Comparable から Object に変更され，

スに追加している．

より広い型の値を受け取るように変更されている．このコミットの変更を受けて (b) のコミットではそのインターフェースを実装するクラスのメソッドの引数も Comparable から Objectに変更されている．

4. スプリットコミット検出手法の提案
提案手法の入力はコミットの組であり，出力はそのコミッ
トの組がスプリットコミットであるかどうかである．提案手

レベル 3：機能レベル法は以下の STEP からなる．

レベル 3 のスプリットコミットはレベル 2 のスプリットコ

STEP1: ソースコード取得

ミットに加えて，1 つの大きな機能を実現するためのコミット

STEP2: グラフ構築の組を指す．レベル 3 のスプリットコミットを用いることで，

STEP3: スコア計算

あるコミットに関連したコミットを探し出すことができる．

STEP4: スプリットコミットの判定—3—

提案手法の概要を図 5 に示す．以降，各 STEP の詳細につ

入力：コミットの組

C1

C2

いて述べる．
STEP1: ソースコード取得
それぞれのコミットの時点でのソースコードを取得する．こSTEP1: ソースコード取得
ソースコードれには Java による Git の実装である JGit [11] を用いた．
STEP2: グラフ構築
取得したソースコードからグラフを構築する．現在の実装

STEP2: グラフ構築

グラフ

では Java のソースコードに限定し，Eclipse Java development
tools (JDT) [12] をソースコードの解析に用いた．JDT による
ソースコードの解析で，ソースコードに含まれているメソッ

STEP3: スコア計算
スコア

ド，各メソッドの定義されているクラス，メソッド同士の呼び出し関係を取得する．この結果から以下の重み付き有効グラ

0.725
STEP4: スプリットコミット判定

フ G = (V, E) を構築する．
• 頂点は，コミット cn ∈ {c1 , c2 } とメソッド m の順序対
(cn , m) とする．これはどちらのコミットのメソッドであるかnを区別するためである．本論文では (cn , m) を m と表す．
• 辺を頂点の順序対 (a, b) とする．辺には Esame ，Ecalling ，≧threshold

出力：スプリットコミット
であるかどうか

Ecalled ，Edef の 4 種類がある．

<threshold

スプリットコミット スプリットコミット
であるでない

図 5 提案手法の概要– Esame は 2 つのコミットで同じメソッド表す頂点同士に張る辺である．辺の重みは 1 とする．

STEP3: スコア計算– Ecalling はメソッド m1 がメソッド m2 を呼び出してい

STEP2 で構成したグラフ上でのメソッド間の距離をもとにるとき， 頂点 mc1 から頂点 mc2 へ張る辺である．辺の重みはスコアを計算する．まず，コミット c1 で編集された各メソッ

wcalling とする．

ドについて，コミット c2 で編集されたメソッドで一番近いも– Ecalled はメソッド m1 がメソッド m2 に呼び出されてのを探索し，そのメソッドまでの距離を求める．コミット c1

いるとき，頂点 mc1 から頂点 mc2 へ張る辺である．辺の重みはのメソッドから，コミット c2 のメソッドへの最短経路には少wcalled とする．メソッド呼び出しの向きによって重さを変化なくとも 1 つの Esame の辺が含まれるため，その距離は 1 以させることができるように 2 種類の辺を定義した．

上となる．次に，各メソッドで求めた距離の逆数をとり，その– Edef はメソッド m1 とメソッド m2 が同じクラスで定平均を s1 とする．s1 は 0 以上 1 以下となる．本研究では一番義されているときに張る辺である．辺の重みは wdef とする．

近いメソッドの探索に Dijkstra 法を用いた．同様にコミット

入力として与えられるコミットを (c1 , c2 ) としたとき，形式

c2 で編集された各メソッドについて，コミット c1 で編集され的な定義は以下のとおりである．

たメソッドで一番近いものまでの距離を求め，求めた距離の逆数の平均を s2 とする．最後に s1 と s2 の平均と，s2 のうちV = {mn | mn はコミット cn ∈ {c1 , c2 } の時点でのソースコードが持つメソッド m}

高いほうをスコアとする．これは予備調査において，古いほ(1)

うのコミット c1 で編集されたメソッドの一部を新しいコミッ
ト c2 においても編集しているスプリットコミットが多く見らE = Esame ∪ Ecalling ∪ Ecalled ∪ Edef

(2)

れたためである．
コミット c1 で編集されたメソッドの集合を V1 ，コミット c2

Esame = {(a, b) | a = m11 ∈ V, b = m22 ∈ V,

で編集されたメソッドの集合を V2 ，頂点 a から頂点 b までの距離を distance(a, b) としたとき，形式的な定義は以下のとお

m1 = m2 }りである．

∪{(b, a) | a = m11 ∈ V, b = m22 ∈ V,
m1 = m2 }

(3)
S1 =

n
Ecalling = {(a, b) | a = mn
1 ∈ V, b = n1 ∈ V,

m1 が m2 を呼び出す }

(4)
S2 =

1 ∑
1
|V2 |
argmin distance(m2 , m1 )(8)

m2 ∈V2 m ∈V
1
1

(5)

n
Edef = {(a, b) | a = mn
1 ∈ V, b = m2 ) ∈ V,

m1 と m2 は同じクラスで定義 }(7)

m1 ∈V1 m ∈V22n
Ecalled = {(a, b) | a = mn
1 ∈ V, b = m2 ∈ V,

m1 が m2 に呼び出される }

1 ∑
1
|V1 |
argmin distance(m1 , m2 )score = max((S1 + S2 )/2, S2 )(9)

STEP4: スプリットコミットの判定(6)

STEP3 で求めたスコアが閾値よりも高ければスプリットコ—4—class B{
void d(){class A{
void a(){
+
+

+
d();

b1

}

}
void b(){a();}
void c(){
}

}

c2

b2

c1

a1

}

a2

(a) コミット c1 でのソースコード

class A{
void a(){d1class B{
void d(){

e2

d2

d();
}
void b(){a();}
void c(){}}void e(){
}

+
+
}

図7

𝐸𝑐𝑎𝑙𝑙𝑖𝑛𝑔

𝐸𝑐𝑎𝑙𝑙𝑒𝑑

𝐸𝑑𝑒𝑓

𝐸𝑠𝑎𝑚𝑒

ソースコードから生成されたグラフ}(b) コミット c2 でのソースコード

いメソッドは d1 であり，その距離は 10/7 = 1.43 である．

図6以上より，s1 = 0.91，s2 = 0.85 である．

例で用いるソースコード

最後にスコアを求めると，score = max((s1 + s2 )/2, s1 ) =ミットであると判定し出力する．

0.88 となり，このコミットの組のスコアは 0.88 である．よっ

スプリットコミット検出の例て，この 2 つのコミットの組はスプリットコミットであるとスプリットコミット検出の例を示す．ここではパラメータ

提案手法は判定する．

として以下の値を用いた．

5. 実

threshold = 0.7((wcalling , wcalled , wdef ) =

3
3 3
,
,
14 14 7

)

(10)
(11)

(

)−1

(

)−1

= 2wcalled + 1(= wdef + 1

)−1

実験方法

提案手法の評価のため，以下の２種類の実験を行った．
実

験

12 章で行った調査によって得られた 2 つのリポジトリのデー

これらの値は以下の式を満たすように定めた．
threshold = 2wcalling + 1

5. 1

験

タセット (100 コミット, 1,714 組, うち 81 組のスプリットコ(12)ミット) に対して提案手法を適用し，スプリットコミットの判(13)定を行った．この判定結果から，提案手法がスプリットコミッ(14)

トであると判定したもののうち実際にスプリットコミットであったものの割合である適合率，スプリットコミットのうちはじめに，入力として与えられたコミットの組 (c1 , c2 ) から，提案手法がスプリットコミットであると判定したものの割合

それぞれのコミットの時点でのソースコードを取得する．コである再現率，およびこれら 2 つの調和平均である F 値を評

ミット c1 の時点でのソースコードを図 6(a)，コミット c2 の時価指標として求めた．

点でのソースコードを図 6(b) に示す．ここで，+ で始まる行
はそのコミットで追加された行，− で始まる行はそのコミッ
トで削除された行を表す．
次に得られたソースコードからグラフを作成する．作成したグラフを図 7 に示す．
次に，編集されたメソッド間のグラフ上での距離を求める．
• コミット c1 で編集されたメソッド a1 からコミット c2
で編集されたメソッドの中でで一番近いメソッドは a2 であり，その距離は 1 である• d1 からコミット c2 で編集されたメソッドの中で一番近いメソッドは a2 であり，その距離は 17/14 = 1.21 である．
• a2 からコミット c1 で編集されたメソッドの中で一番近いメソッドは a1 であり，その距離は 1 である．
• e2 からコミット c1 で編集されたメソッドの中で一番近

実

験

2

調査区間よりも広い区間（331 コミット，18,619 組）に対して提案手法を適用し，スプリットコミットの判定を行った．この判定結果のうち，提案手法がスプリットコミットであると判定したコミットの組が本当にスプリットコミットであるか
目視で確認し，適合率を評価指標として求めた．
5. 2

実験結果

実験 1 の結果を表 3 に示す．F 値は，Apache では 0.714，
表 3 データセット 1 での実験結果
適合率 再現率

F値

Apache

0.714

0.714

0.714

Retrofit

1.000

0.594

0.745

—5—

Retrofit では 0.745 であった．スプリットコミットでないもの

81 組のスプリットコミットを発見した．また，発見したスプをスプリットコミットとして判定してしまったものには，プ

リットコミットを 3 つのレベル分類した．次に，目視によるログラムのエントリーポイントなど，多くのコミットで変更

調査から得られたスプリットコミットの特徴を利用したスプされるメソッドをそれぞれのコミットで変更したものがあっ

リットコミットの自動検出手法を提案した．提案手法を用いた．スプリットコミットであるものをスプリットコミットでた実験では F 値 0.7，適合率 0.8 の精度でスプリットコミット

ないと判定してしまったものには，コミットに複数のタスクを検出することができた．

が含まれており，そのうち一部のタスクのみが両方のコミッ
トに含まれているコミットがあった．

本研究の貢献は以下の通りである．
• 1 つのタスクが複数のコミットに分割されているコミッ

実験 2 の結果を表 4 に示す．適合率は，Apache では 0.822，

トであるスプリットコミットがリポジトリに含まれているこ

Retrofit では 0.884 であった．よって，提案手法はより大きなとを示した．
• スプリットコミットの自動検出手法を提案し，2 つのリ

データセットに対しても有効である．
検出されたスプリットコミットの例を以下に示す．
• Retrofit リポジトリの 2010/11/24 08:09 のコミット

ポジトリを用いて評価を行った．

#57a57d2 と 2010/11/24 08:23 のコミ ット#1eab56a がスプ

今後の課題は以下の通りである．
• より多くのリポジトリに対して実験を実行

リットコミットとして検出された．このコミットの組では•提案手法を実装した Eclipse プラグインの開発#57a57d2 で編集したメソッドのソースコードを#1eab56a コ•

スプリットコミットの情報を用いたコミットの自動ク

ミットで整形していた．これらのコミットを 1 つにまとめる
ことで，コミット履歴を簡潔にすることができる．
• Apache Commons Collections リ ポ ジ ト リ に あ る

ラスタリング手法の検討
謝辞

究（S）（課題番号：JP25220003）の助成を得て行われた．

2002/03/02 から 2002/03/20 にかけての 6 つのコミットの中から，13 組がスプリットコミットと判定された．各コミッ
トの変更内容を表 5 に示す．表の示す通り，これらの 6 つのコ
ミットはすべて ComparatorChain クラスに関する変更であっ

文
[1]
[2]
[3]

た．このようにレベル 3 スプリットコミットは，ある機能に関するコミットの検索に有効である．

[4]

6. 妥当性の脅威
対象コミット：本研究ではリポジトリのコミットの中でも[5]開発序盤のコミットのみが対象であった．開発後半のコミッ
トでは本研究と違う結果となる可能性がある．
目視での確認：調査や実験での正解データは目視により作[6]成したため，データを作成した者の主観に依存している．

7. あ と が き[7]

本研究ではまず，2 つのオープンソースソフトウェアのリポ
ジトリに対して調査を行い，1,714 組のコミットの組の中から[8]

表 4 データセット 2 での実験結果
検出数 正解数

適合率

Apache

416

342

0.822

Retrofit

95

84

0.884

[9]

[10]
表5

検出されたコミットの変更内容

日時

コミット ID

変更内容
ComparatorChain クラスを追加

2002/03/02 08:29#5ae8487

2002/03/02 08:40#c55fe26

メソッドを 2 つ追加

2002/03/02 08:48#f247986

リストを防御的コピーに変更

2002/03/05 04:18#5155b93

コメントとメソッドを追加

2002/03/20 07:25#54c23b2

メソッドとテストケースを追加

2002/03/20 09:25#d0d74a4比較関数を修正

本研究は，日本学術振興会科学研究費補助金基盤研

[11]
[12]

献

“Git - Book”. https://git-scm.com/book/en/v2/
S. Berczuk and B. Appleton, Software Configuration Management Patterns, Addison-Wesley, 2002.
K. Herzig and A. Zeller, “The impact of tangled codechanges,” Proceedings of the 10th Working Conference on
Mining Software Repositories, pp.121–130, May 2013.
切貫弘之，堀田圭佑，肥後芳樹，楠本真二，“ソースコード中の変数間のデータ依存関係を用いたコミットの分割，” 電子情報通信学会技術研究報告，vol.113，no.269，pp.67–72，Oct. 2013．
A. Hindle, D. M. German, and R. Holt, “What do large commits tell us?: A taxonomical study of large commits,” Proceedings of the 5th Working Conference on Mining Software
Repositories, pp.99–108, May 2008.
J. M. Bieman, A. A. Andrews, and H. J. Yang, “Understanding change-proneness in OO software through visualization,”
Proceedings of the 11th IEEE International Workshop on
Program Comprehension, pp.44–53, May 2003.
H. Gall, K. Hajek, and M. Jazayeri, “Detection of logical coupling based on product release history,” Proceedings of theInternational Conference on Software Maintenance, pp.190–
198, Bethesda, Maryland, USA, Nov. 1998.
T. Zimmermann, P. Weißgerber, S. Diehl, and A. Zeller,“Mining version histories to guide software changes,” IEEE
Transactions on Software Engineering, vol.31(6), pp.429–445,
June 2005.
“GitHub
apache/commons-collections:
Mirror of
Apache Commons Collections”．https://github.com/apache/commons-collections“GitHub - square/retrofit: Type-safe HTTP client for Android and Java by Square, Inc.”. https://github.com/square/retrofit“JGit”. http://www.eclipse.org/jgit/“Eclipse Java development tools (JDT)”. http://www.eclipse.
org/jdt/—6—