Which Change Sets in Git Repositories Are Related?

Abstract

Abstract-Software repositories contain valuable information about the history of software changes. Using data mining, researchers have identified file changes that happened together frequently to present hints for necessary changes to developers. However, not all file change sets are related. This can affect the recommendations about coupled file changes negatively by delivering irrelevant couplings to the developers. The commit time and branching characteristics of Git have not been investigated together in previous heuristics for grouping related change sets. We exploit the mappings between commit messages and issue ids for judging the relatedness of change sets. We propose a heuristic for Git and investigate the influence of two factors, the time between the commits and their branching on the relatedness of change sets using the repositories of five open-source systems using logistic regression. According to our findings, the combination of these two factors influences the relatedness of change sets. Individually measured, only the time significantly influences the relatedness, the branching itself does not. Our results support previous heuristic that also in Git repositories the commit time is important for grouping related change sets.

Comparison of version control system tools

“…It is one of the easy and simple forms of version control, save all the modifications to the files under revision control in a database [21]. CVCS are called centralized because there is only one central server or repository holding the version database where the developers check out their projects on their local computers [19]. The server can be accessed via the network [4].…”

“…Git became very widespread in the open-source community because it supports parallel collaborative work, and offers some very interesting advantages, such as resolving conflicts that arise during synchronization of parallel but that is modifications take time-consuming [7]. An important attribute of Git is the method it handles the time of modifications in the source code, it tracks only the time of commit, and also support branches, and this allows developers to create several lines of development and merging them [19]. One of the most important differences between Git and other VCS is the way how Git treats data.…”

“…The distributed version control system does not have a central server [14]. In DVC, each team member owns the full repository on the local development machine called the local repository, the developers can copy the remote repository into their local repositories and commit to the local repository [19]. In DVC, backups are taken to the server repository, guarantee that all committed modifications are considered during the backup process.…”

“…A centralized version control system environment grants anyone to modify any a portion of their native repositories past events [14]. In DVCS, file modifications are organized in commits, where the information about the commit time and the branching is preserved, branching is used to separate commit modifications from each other [19], CVCS have similar workflows. In contrast, DVCS is very flexible and one can adjust the setup of DVCS to fit one's needs [4].…”

“…The version control systems are not only related to the modifications of data, but also the reasoning behind the modifications. VCS stores information about which files were modified, when they were modified, who made the modification and what the files contained before the modification [19], as well as help developers to know who works on these files [9]. So, VCS allows the developers to cooperate and work on the same software project at the same time [12].…”