IPSJ SIG Technical Report

Investigating the impact of source code metrics onmerge conﬂict resolution judgement model
Mohan Bian1,a)Tetsuya Kanda1,b)

Kazumasa Shimari1,c)Katsuro Inoue1,d)Abstract: In large-scale software development, a version control system is frequently used. However, if multiple persons change the same piece of code in parallel, conﬂicts may occur. In order to merge the changes
successfully, the developer must investigate the cause, re-edit the code. This can take hours or even days,
delaying the project’s development schedule while the developer repeatedly reviews to identify the reason forthe conﬂict and ﬁnd a solution. In the previous research, a machine learning model was created to determine
how to solve merge conﬂicts from meta information such as the number of lines of merge conﬂicts, the date
and time when commits were created, and the developers who created them. In this research, by adding
source code metrics to the model, we aim to create a model that suggest how to resolve appropriate merge
conﬂicts with higher accuracy.

1.

Introduction

In large-scale software development projects, it is common
for multiple developers to work together. For multi-person
development, it is necessary to record information such as“when”, “who”, and “what changes were made” for trouble
shooting afterwards. To record these information, a version
control system was frequently used. Version control systems
enable us to access the revision history of each branch, whichmake it much easier for parallel developing. While projects
can be eﬃciently developed by multiple people, parallel development may cause problems. After editing a newly created branch from the mainstream, if the mainstream also
edits the same piece of code, there will be a situation where
it cannot be merged when merging it into the mainstream.
This is called a merge conﬂict. Merge conﬂict is one of themost annoying problems. It has been clariﬁed that it occurs
relatively frequently in software development using a version
control system. In the research by Brun et al., as a resultof investigating the development history of nine open-source
software (hereinafter, OSS) , merge conﬂicts occurred in all
projects. It has been shown that the ratio of merge conﬂicts occurs to all merges is about 19% on average and the
maximum is about 42% [1].
The problem with merge conﬂict is that it takes time andeﬀort to resolve them. If a merge conﬂict occurs, the developer must investigate the cause, re-edit the code, and debug
until the merge is successful. This can take hours or even
1
a)
b)
c)
d)

Osaka University
hen-bk@ist.osaka-u.ac.jp
t-kanda@ist.osaka-u.ac.jp
k-simari@ist.osaka-u.ac.jp
inoue@ist.osaka-u.ac.jp© 1992 Information Processing Society of Japan

days, delaying the project to the development schedule while
the developer repeatedly reviews to identify the reason forthe conﬂict and ﬁnd a solution [2].
In some existing studies, the characteristics of merge conﬂicts and their resolution methods have become clear. It
has been clariﬁed that the higher the number of lines where
merge conﬂicts occur, the higher the rate of merge conﬂicts
would be [3]. Shiraki et al. [4] proposed a machine learningmodel to determine how to resolve merge conﬂicts from meta
information such as the number of lines of merge conﬂicts,
the date and time when commits were created, and the developers who created them. It became clear that the numberof lines of the merge conﬂict contributes to the method ofresolving the merge conﬂict.
Ahmed et al. have also shown that bugs lead to merge
conﬂicts [5]. Bad code design not only impacts maintainability, it also impacts the day-to-day operations of a project,such as merging contributions. Ahmed et al. indicate that
research is needed to identify better ways to support merge
conﬂict resolution to minimize its eﬀect on code quality. In
other research, it became clear that the complexity of the
program measured by the source code metrics is also related
to the defects of the program [6]. From the above, we realized it is possible that source code metrics are potential
indicators of merge conﬂict. By adding source code metrics to the machine learning model proposed by Shiraki etal., we aim to create a model that suggests how to resolve
merge conﬂicts with higher accuracy. In addition, we investigate the importance of source code metrics contributes tothe machine learning model and compare the importance offeatures in case of Java and Python projects.
In this paper, Section 2 describes the background of the1

IPSJ SIG Technical Report

Fig. 2Evolutionary commit and the distance.

way [8].

Fig. 1

An example of merge conﬂict.

research, Section 3 introduces the previous research, Section 4 proposes methods for model extension and parameter
improvement, and Section 5 evaluates the improved model.
Section 6 discusses the limitations of this study. Finally, wesummarize the research in Section 7.

2.

Background

2.1 Merge Conﬂict
In Git, a repository is created locally and most of the development is done in the local environment, and work is donein units called branches. Merge is a way to bring branches
back. The git merge command is a command created using
git branch to merge multiple independent branches. However, if diﬀerent edits in the same piece of code are detectedin both commits, a merge conﬂict will occur.
In merging, 3-way merging is common. Figure 1 shows anexample of a 3-way merge conﬂict. A branch is created inancestor commit P, and commit P1 is created with edits toline 10. Next, another branch is created from commit P, andcommit P2 is created with another compilation for the line
10. Commit P1 and P2 are a commit pair to merge. Then,commits P1 and P2 try to merge their respective revisions.
Currently, there are duplicates in the edited part, so thata merge conﬂict occurs when merging those two branches
systematically.
In addition to textual conﬂicts, there are merge conﬂicts
called build conﬂicts and test conﬂicts [1][7]. Build conﬂicts
and test conﬂicts appear to be successfully merged in thetext, when you actually run a program build or test, you
get an error due to a merge. Building conﬂicts and test conﬂicts have been found to be less than half as likely as textual
conﬂicts [7]. Therefore, this study does not deal with build
conﬂicts, and hereafter, merge conﬂicts refer to textual conﬂicts.
2.2 Solution of Merge Conﬂict
Regarding the speciﬁc method of resolving merge conﬂicts, there are many cases where the merge conﬂict is resolved by adopting the editing of one of the commit pairand deleting the other one as shown in Figure 1. A study
by Yuzuki reveals that about 98% of all merge conﬂicts that
occur within methods in Java projects are resolved in this© 1992 Information Processing Society of Japan

2.3 Evolutionary Commit and DistanceIn each of the commits P1 and P2 where the merge conﬂict
occurred, there is a commit edited in the branch from thecommon ancestor to P1 and P2. Of all the edited locations
where merge conﬂicts occur, the commits closest to P1 andP2 are called Evolutionary Commits [9]. In the previous research, the distance between the Evolutionary Commit andthe commit in which the merge conﬂict occurred was obtained and used to create the model. The number between
green and red commit in Figure 2 is the distance explained
above.
2.4 Source Code Metrics
Source code metrics are measurements of various aspectsof software code. Some metrics are at an higher level, spanning the entire code, while others are at a lower level, covering classes, methods, or even smaller blocks of code. For
example, the number of the lines of code, the number ofcomments in the code, the number of variables, functions,developers, and so on. In these metrics, a lot of valuable
information about the program is hidden. For example, in
Meirelles s study, the relationship between source code metrics and the attractiveness in free software projects has become clear [10]. They suggest software projects with higher
structural complexity have lower attractiveness. On theother hand, projects with more lines of code have higher
attractiveness. Lanubile et al. [6] shows that source code
metrics are related to the defects of the program. Since thesource code metrics can tell us so many valuable information, it is quite possible that the metrics we get from thesource code in the development history would give us useful
information related to merge conﬂict.
2.5 ANTLRANTLR*1 is a lexer and parser generator aimed at building and walking parse trees. ANTLR makes it eﬀortless
to parse nontrivial text inputs such as a programming language syntax. It is a tool that automatically generates a
so-called analyzer, which is a function required for parsing
an abstract syntax tree, using a grammar ﬁle as input. Since
the grammar ﬁle does not depend on the programming language of the analyzer, it is possible to generate an analyzer
for multiple programming languages. The analyzer consists*1

https://www.antlr.org/

IPSJ SIG Technical Report

Fig. 3

Flow of the input and output of Lexer.

Fig. 5Distinguishing Commit Pairs with Merge Conﬂicts*1 .

Table 1Deﬁnition of merge conﬂict resolution instruction in Shiraki et al.’s study.
ADOPT
DELETEEDIT
ZEROTable 2
Fig. 4Merge conﬂict resolution model proposed in previous research*1 .

of three parts: Lexer, Parser, and Listener. In the experiment we only used Lexer, Figure 3 shows the ﬂow of how
Lexer works.
Lexer is a procedure that analyzes character strings suchas natural language sentences and programming language
source code to obtain a sequence of “tokens”, which is thesmallest unit in parsing (shown in Figure 3). Parser is aprocess that reads the text to be analyzed and decomposes
it into a syntax tree. Listener is an API for users to create
their own analyzer.
In this study, in order to obtain the source code metrics, Lexer is used to decompose source code into the smallest unit “token”, and the source code metrics are obtained
from there. In this paper, we will analyze Java projects
and Python projects. Since a grammar ﬁle is required foreach language, it is necessary to generate Lexer using thegrammar ﬁles for Java language and Python language, respectively.

3.

Previous research

In this research, we extend the model created in previous research. In this section, we will explain the previous
research by Shiraki et al and their results.
3.1 Experimental Approach
They aimed to suggest to developers how to resolve merge
conﬂicts when they occur. According to the research by
Yuzuki [8], it is often resolved by adopting one and deleting the other for the commit pair when the merge conﬂict
occurred. Based on this result, Shiraki et al. proposed amethod for resolving merge conﬂicts using machine learning.
They created a judgement model (shown in Figure 4) for
determining the method for resolving merge conﬂicts fromdevelopment history information related to merge conﬂicts
that occurred in the past. To build the model, random forest© 1992 Information Processing Society of Japan

Adopt all edits
Delete all edits
Make edits
0 lines to edit

Parameters used to build the model.
Parameterlinenum(P1)time(P1)
P1
author ratio(P1)distance(P1)linenum(P2)time(P2)
P2
author ratio(P2)distance(P2)linenum(d)time(d)Diﬀerenceauthor ratio(d)distance(d)is used as the learning algorithm.
3.2 Data Collection
In the previous research, 20 Java projects were collectedfrom the OSS provided by Apache. The determination of theresolution method by the judgement model is performed foreach commit pair in which a merge conﬂict has occurred. As
shown in Figure 5, to distinguish each commit of the commit
pair, P1 is the commit on the mainstream branch and P2 isthe commit on the newly derived branch.
The resolution method proposed to developers is a set of
instructions for each commit (P1 resolution instruction / P2
resolution instruction). Table 1 deﬁnes the list of resolution
methods for each commit.
Development history information was acquired from therepository for each commit P1 and P2 in which a merge
conﬂict occurred. Table 2 is the list of parameters used tocreate the machine learning model. linenum is the numberof lines where merge conﬂicts occur, time is commit creation
date and time, author ratio is the ratio of commit creatorto total commit number, distance is the distance between
current commit and its Evolutionary Commit. P1 is the parameter from mainstream, P2 is the parameter from branch,and diﬀerence is the subtraction of P1 and P2.
*1

Shiraki et al.,Judgment Model of Merge Conﬂict Resolution Pattern Using Machine Learning Meta-Information,IEICE
Technical Report,2020

3

IPSJ SIG Technical Report

Table 3

Source code metrics to get.

P1

P2

Diﬀerence

Fig. 6

An overview of the model proposed in this research.

3.3 Experiment result
20 Java projects collected from the OSS provided by
Apache were used for the experiment. The accuracy is a result of cross-validation by dividing the merged conﬂict data
into ﬁve for each project. The accuracy was 66.41% on average and 94.43% at maximum. It became clear that thesolution method can be determined with high accuracy.
To ﬁnd out which parameter the created model determines the resolution method, an index called importance isused. Importance is the percentage of each parameter contributing to the classiﬁcation in the model, and the sum of
the importance of all parameters is 1. The number of lines
line num (P1) and line num (P2) where merge conﬂicts occur are both as large as 0.15 or more. So, it can be said thatthe number of lines where conﬂicts occur greatly contributes
to the determination of how to resolve merge conﬂicts in any
project.

4.

Model Expansion

The goal of this research is to improve the prediction accuracy by improving the existing feature and adding new
metrics extracted from source code. An overview of themodel is shown in Figure 6.
Shiraki et al.’s method [4] used only language-independentfeatures. However, as introduced in Section 2, source code
metrics also possibly have an eﬀect on software quality.
Therefore, we add source code metrics to this model to see
how the accuracy changes. We also aim to verify whether
a judgement model should be created for each language orregardless of the language. Since merge conﬂicts often occur
in parallel development using Git regardless of programming
language, another goal of this research is to help resolve
merge conﬂicts not only in Java language projects but also
in other languages.
4.1

New judgement model by adding code metrics
Some studies have also shown that bugs lead to merge conﬂicts [5]. In other research, it has become clear that the complexity of the program calculated by the source code metrics
is also related to the defects of the program [6]. Therefore,
it is quite possible that there is a connection between merge
conﬂict and the complexity of the program calculated by the© 1992 Information Processing Society of Japan

Name Num(P1)
Operator Num(P1)
Keyword Num(P1)
Name Num(P2)
Operator Num(P2)
Keyword Num(P2)Name Num(d)Operator Num(d)Keyword Num(d)source code metrics.
There are many source code metrics show the complexityof the program. For example, Cyclomatic complexity, number of lines of code, number of methods, number of function
calls, and so on. It is conceivable that complicated programs
tend to have a large amount of information. Considering thecost of extracting the source code metrics, we decided touse source code metrics that can be easily get. Metrics that
represent the amount of information can be easily obtained
including the number of lines in the program in which themerge conﬂict occurred, the number of variables and functions, the number of operators, and the number of keywords.
And since the number of lines of each commit has alreadybeen acquired in previous research, this time we will add thenumber of variables and functions, the number of operators,
and the number of keywords words as source code metrics
for building the new model. Table 3 shows the new metrics to get for the judgement model. Name Num represents
the number of variables and functions, Operator Num is thenumber of operators and Keyword Num is the number of keywords. Same with previous research, P1 is the parameterfrom mainstream, P2 is the parameter from branch, and diﬀ
is the subtraction of P1 and P2.
4.2 The method of extracting code metrics
The method of getting the code metrics from development
history can be described into several steps:( 1 ) Get the development history ﬁle contents corresponding
to ﬁle path and commit( 2 ) Generate the Lexer of Java or Python according to theproject language( 3 ) Pass the ﬁle contents as strings to Lexer to obtain asequence of “tokens”( 4 ) Implement a program to stat the number of the metrics
in needFirst of all, we used git show command: “git showcommitHash:/path/to/ﬁle” to get the developing history ﬁlecontents corresponding to ﬁle path and commit hash. The
way of getting the source code metric is by using a language
recognizer. We used ANTLR introduced in Section 2.5 togenerate a Lexer from Java and Python grammar ﬁle respectively. Then we used Lexer of each language to analyze
projects in each programming language source code to obtain a sequence of “tokens”, which is the smallest unit inparsing. Figure 7 describes the ﬂow of source code metrics
extraction.
According to the grammar ﬁle, thirty-four kinds of op-

IPSJ SIG Technical Report

Fig. 9Fig. 7

The new time feature Fixed time1, Fixed time2 used inthis research.

The ﬂow of source code metrics extraction.

ration from each commit’s creation time to the merge time
as Time1 and Time2 in seconds. In Figure 7, Fixed time1,
Fixed time2 show the time from each commit’s creation
time to the merge time. Fixed time1, Fixed time2, as wellas Fixed timeD(subtraction of Fixed time1, Fixed time2)
which are updated as features for the new model.

5.

Fig. 8The time feature used in previous research.

erator and ﬁfty kinds of keyword are deﬁned for Java andthirty-nine kinds of operator, and thirty-ﬁve kinds of keyword are deﬁned for Python.
Finally, we implemented a program to count the numberof variables and functions, the number of operators, and thenumber of keywords from the tokens, which are the sourcecode metrics needed for building the new model.
4.3 Parameter Improvement
In the previous research, the creation dates and times ofcommits P1 and P2 were acquired and used as features ofthe learning model. For example, if a commit was created at
12:30:25 on May 21, 2019, it would feature an 8-digit date“20190521” and a 6-digit time “123025”, a total of 14-digit
numbers “20190521123025”(shown in Figure 8).
It is a quantity and since the subtraction of the time ofP1 and the time of P2 is also subtracted as a decimal number of 14 digits, its usage is a little inconsistent with theconcept of time. In Costa et al.’s research [11], factors that
contribute to the occurrence of conﬂicts are listed as number of changed ﬁles, number of changed lines, number ofcommits, number of developers, branching-duration, lackof communication, developer working in several branches
and so on. They asked 109 software developers to conduct a survey on factors that they think lead to conﬂicts.
In this question, participants were allowed to mark morethan one answer. 76 (69.7%) developers marked the option“branching-duration”. From this result, it is considered thatthe time from each commit’s creation time to the merge
time is more related to the merge conﬂict than the commit
creation date and time. Therefore, we calculated the du-© 1992 Information Processing Society of Japan

Evaluation

In order to investigate the eﬀectiveness of the source code
metrics for the judgement model, we conducted evaluation
experiments on Java projects and Python projects with andwithout the source code metrics. Same with Shiraki etal.’s research, 20 Java projects were used from the OSS
projects published by the Apache Software Foundation. For
the Python project, 15 new OSS projects published by the
Apache Software Foundation are selected in order of popularity. Projects with no conﬂicts and projects with extremely few conﬂicts (less than 10) are excluded, and 8
projects remained. Table 4 shows the list of projects usedin the experiment and the number of merge conﬂict.
20 java projects and 7 python projects were used in theexperiment. For each project, the accuracy is a result ofcross-validation by dividing the merged conﬂict data intoﬁve. The learning algorithm Random Forest was used.
After modifying the parameter in Shiraki et al.’s research,
the accuracy of the model increased from 66.41% to 74.99%
in case of Java project, and 55.32% to 61.87% in case of
Python project. From the result, it is clear that the newparameter Fixed time1, Fixed time2 deﬁned contribute
more to the model.
5.1

RQ1: How does the accuracy of the modelchange if both developing history data andlanguage-speciﬁc source code metrics areused in the model?
In the case of Java, the average accuracy of the modelchanged from 74.99% to 75.54%. In Python, it changed
from 61.87% to 61.76%, which were almost unchanged.
Figure 10 shows the ratio of source code metrics(the grey
area pulled out by the line) to all features. The blue zone
represents the parameter importance of mainstream, the redzone represents that of branch, the green zone represents
that of the subtraction of mainstream and brunch. Source

5

IPSJ SIG Technical Report

Fig. 10

Table 4

Importance of source code metrics in case of Python and Java.

List of Java and Python projects used in the experiment.
Java project(20 in total)
project name# merge conﬂict
beam
1,449
camel
44
cassandra
17,837
cordova-android
973
curator
287
dubbo
401
ﬂink
3,454
geode
573
groovy
353
hbase
187
hive
3,246
ignite2,850
incubator-heron61
jmeter693
lucene-solr
2,562
mahout
195
maven
251
niﬁ
157
nutch
658
rocketmq
56
Python project(8 in total)
project name# merge conﬂict
airavata72
airﬂow
61
allura28
cassandra
200
incubator-datalab449
incubator-spot
10
libcloud
2,082
predictionio
14

code metrics (9 in total) are 29.32% for Java and 26.65% forpython . Among all the 9 source code metrics, d NameNum,d OperatorNum, and d KeywordNum came to the top in bothJava and Python projects. These three metrics are all thediﬀerence of code metrics for each commit pair. Therefore,
from the source code metrics extracted from each commit
pair, it was found that the diﬀerence between the sourcecode metrics of the two commits contributes more to theresult of the judgement model than the metrics extracted
from each commit.
Since the diﬀerence of code metrics from two commits© 1992 Information Processing Society of Japantend to have stronger relevance, we made another experiment of the model only consist of the diﬀerence of code
metrics and parameters used in Shiraki et al.’s model. Table 5 shows the parameter and the accuracy of each model.
As a result, source code metrics are about one-third asimportant in the two languages. However, there was a variation in the total importance of the source code metrics.
Table 6 shows the importance of code metrics in each Javaproject.
In case of Java project, the maximum was 55.37% forproject jmeter, compared to only 11.49% for project hbase.
When we checked the source code metrics, the diﬀerence
between the source code metrics obtained from each commitd NameNum, d OperatorNum, and d KeywordNum were large inof some of the projects. These projects’ source code metrics tend to have larger importance. On the other hand,when the metrics taken from each commit are almost thesame, d NameNum, d OperatorNum, and d KeywordNum would
be almost 0. In this case, source code metrics did not makecontributions to the decision model.
From the above, it became clear that source code metrics
are not useful if each commit does not change the numberof names, the number of operators, and the number of keywords. For example, if two developers only change the nameof the variable or function, the number of names stays thesame. Also, if two developers add a similar piece of code
or change the order of the code in a program, the diﬀerence
between two commits still stays the same as before. In thiskind of situation, source code metrics may not contribute asmuch as we expected.
In conclusion, the source code metrics may not contributeto the model as much as the feature existed, but the diﬀerence of the code metrics from each commit pair surely has
an inﬂuence on the model.

IPSJ SIG Technical Report

Table 5 Parameters used in each model.
improved Shiraki et al.’s model
expanded model

parameter

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

linenum(P1)
Fixed time(P1)author ratio(P1)distance(P1)linenum(P2)
Fixed time(P2)author ratio(P2)distance(P2)linenum(d)Fixed time(d)author ratio(d)distance(d)Name Num(P1)
Operator Num(P1)
Keyword Num(P1)
Name Num(P2)
Operator Num(P2)
Keyword Num(P2)Name Num(d)Operator Num(d)Keyword Num(d)Java Accuracy
Python Accuracy

expanded model(diﬀerence only)
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
75.54%
61.76%

74.99%
61.87%✓✓✓
75.01%
65.77%

Improved Shiraki model
16.00%
14.00%
12.00%
10.00%
8.00%
6.00%
4.00%
2.00%
0.00%
line_num1

distance1

Fixed_time1 author_ratio1

line_num2

distance2

Fixed_time2 author_ratio2 d_line_num

d_distance

Fixed_timeD d_author_ratio

Expanded model
14.00%
12.00%
10.00%
8.00%
6.00%
4.00%
2.00%

Fig. 11

5.2

2
um

d_
Na

m

eN
d_
um
Op
er
at
or
N
d_
um
Ke
yw
or
dN
um

2
w
or
dN

Ke
y

2

Nu
m

Op
e

eN
Na
m

ra
to
r

um

1

1

um
w
or
dN

Ke
y

1
um

Nu
m

ra
to
r

Op
e

eN

Na
m

r_
ra
t

th
o

PythonFeature importance in case of Java and Python.

RQ2: How is the developing history datathat contributes to the judgement diﬀerent
between Java and Python language projects?
There are 21 features in total, including 12 metrics acquired from the development history and 9 extra source code
metrics extracted from the source code this time. In Figure
11, each feature is a comparison of importance in Java andPython. From this ﬁgure, it can be seen that Java projectfeatures that are of high importance tend to have high importance in Python as well. The same result came up even

© 1992 Information Processing Society of Japan

io

eD

Java

d_
au

nc
e

_t
im

ed
Fix

d_
di
st
a

um

io
2

e_
n
d_
lin

e2

or
_r
at

_t
im
ed

au
th

Fix

2

nc
e2
di
st
a

io
1

e_
nu
m

lin

1

e1

or
_r
at

_t
im
ed

Fix

au
th

di
st
a

e_
nu
m
lin

nc
e1

0.00%

when building the model without the source code metrics. It
became clear that line num, distance, Fixed time, andthe diﬀerences in the source code metrics of commit pair
were of high importance. In conclusion, it was found thatthe source code metrics extracted from each language hadno language-dependent characteristics, in other words, Javaand Python language don’t have obvious diﬀerences in thenumber of variables and functions, operators and keywords.
In this research, we got the source code metrics from theentire ﬁle for each commit pair. From the result, the diﬀer-

7

IPSJ SIG Technical Report

Table 6

Importance of source code metrics (CM) in each Javaproject.

project name
beam
camel
cassandra
cordova-android
curator
dubbo
ﬂink
geode
groovyhbase
hiveigniteincubator-heron
jmeterlucene-solr
mahout
maven
niﬁ
nutch
rocketmq
average

expanded model
95.91%
83.33%
66.58%
71.43%
66.18%
61.70%
76.26%
72.41%
89.55%
60.98%
70.90%
81.23%
35.71%
98.50%
73.87%
91.11%
84.78%
66.67%
81.38%
82.35%
75.54%CM importance
31.54%
37.36%
35.04%
21.55%
37.48%
17.23%
29.78%
24.47%
35.71%
11.49%
23.62%
27.52%
28.29%
55.37%
19.04%
23.14%
36.64%
29.29%
33.78%
28.10%
29.32%

ence between the source code metrics extracted from commit pairs contributed more to the judgement result than
metrics from each commit. Therefore, instead of the wholeﬁle, source code metrics extracted from lines where conﬂict
occurs may be more useful for the model creation.
In conclusion, the features used for building the model
don’t have obvious diﬀerences between Java and Python language.

6.

Limitations

All the projects used in this study are OSS provided by
Apache, and there is no certainty that the results will besimilar to the results of this study in other OSS or othercommercial projects. In addition, among the OSS provided
by Apache, the number of python projects is smaller thanJava, so it is diﬃcult to evaluate with data of the same
scale. In the future, it will be necessary to conduct research
not only on Apache but also on various projects in various
languages.
Moreover, as the information used for the parameters ofmodel creation, we traced back to the development history
and used the metrics extracted from the source code of theﬁle during the development. It is possible that some hidden
valuable information that has not been used this time, so
the combination of parameters used by the model created inthis study is not always optimal. However, from the accuracy obtained in this study, it can be said that the model inthis study may be useful for resolving merge conﬂicts.

7.

project tend to be of high importance also in Python.
Also, if the diﬀerence between each commit pair is signiﬁcant, the source code metrics in the decision model tend
to contribute more. However, if the diﬀerence between themodiﬁcations of the commit pair is small, the contributionof the source code metrics tend to decrease. From this result, it is considered that the importance in the judgement
model may be higher when the source code metrics are extracted only in the part where the conﬂict occurs, not in thewhole source ﬁle.
Since diﬀerent languages have diﬀerent grammar, it is necessary to extract source code metrics for each language, butthere is also a lot of language-dependent information that remains hidden. Therefore, it is possible that there is room forfurther improvement in accuracy by increasing the kinds ofsource code metrics in each language in the future. When adeveloper encounters a merge conﬂict, the judgement model
can be useful as a reference to determine how to resolve it.

Acknowledgment
This work was supported by JSPS KAKENHI Grant
Numbers JP18H04094 and JP19K20239.
References
[1]

[2]

[3]

[4]

[5]

[6]
[7]

[8]

[9]

Conclusion

Using the information in the development history, we proposed a model that traces back to the ﬁle contents during thedevelopment phase, extracts the metrics, and contributes
to a judgement model based on the source code metrics.
As a result of comparing the judgement results of the Java
language project and the python language project, it canbe seen that the features with high importance of the Java© 1992 Information Processing Society of Japan

[10]

[11]

Brun, Y., Holmes, R., Ernst, M. D. and Notkin, D.: Early
Detection of Collaboration Conﬂicts and Risks, IEEE Transactions on Software Engineering, Vol.39, No.10, pp. 1358–
1374 (2013).
Kasi, B. K. and Sarma, A.: Cassandra: Proactive Conﬂict
Minimization through Optimized Task Scheduling, International Conference on Software Engineering (ICSE), pp. 732–
741 (2017).
Dias, K., Borb, P. and Barretoa, M.: Understanding predictive factors for merge conﬂicts, Understanding predictive
factors for merge conﬂictsInformation and Software Technology, Vol. 121, No.106256 (2020).
Shiraki, S., Kanda, T. and Inoue, K.: Judgment Model ofMerge Conﬂict Resolution Pattern Using Machine Learning Meta-Information, IEICE Technical Report, Vol. 119,No. 451, pp. 61–66 (2020).
Ahmed, I., Brindescu, C., Mannan, U. A., Jensen, C. andSarma, A.: An Empirical Examination of the Relationship
Between Code Smells and Merge Conﬂicts, In International
Symposium on Empirical Software Engineering and Measurement(ESEM), pp. 58–67 (2017).
Lanubile, F., Ebert, C., Prikladnicki, R. and Vizcaı́no, A.:
Collaboration Tools for Global Software Engineering, IEEE
Software, Vol. 27, No. 2, pp. 52–55 (2010).
Brun, Y., Holmes, R., Ernst, M. D. and Notkin., D.: Proactive Detection of Collaboration Conﬂicts, European Software
Engineering Conference and Symposium on the Foundationsof Software Engineering (ESEC/FSE), pp. 168–178 (2011).
Yuzuki, R., Hata, H. and Matsumoto, K.: How we resolve
conﬂict: an empirical study of method-level conﬂict resolution, 2015 IEEE 1st International Workshop on Software
Analytics (SWAN), pp. 21–24 (2015).
Mahmoudi, M., Nadi, S. and Tsantalis, N.: Are Refactorings
to Blame? An Empirical Study of Refactorings in Merge
Conﬂicts, International Conference on Software Analysis,
Evolution and Reengineering(SANER), pp. 151–162 (2019).
Meirelles, P., Jr., C. S., Miranda, J., Kon, F., Terceiro,
A. and Chavez, C.: A Study of the Relationships between Source Code Metrics and Attractiveness in Free Software Projects, Brazilian Symposium on Software Engineering (2010).
Costa, C., Menezes, J., Trindade, B. and Santos, R.: Factorsthat Aﬀect Merge Conﬂicts: A Software Developers Perspective, Brazilian Symposium on Software Engineering, pp.
233–242 (2021).