Introduction.tex

\footnotetext{\IEEEauthorrefmark{1} First and second author contributed equally to this work.}

\section{Introduction}\label{introduction}

Collaborative development is essential for the success of large projects~\cite{hattori2010syde}, and is enabled by version control systems. 
In Git and other version control systems, practitioners work on their changes in seclusion, and periodically synchronize them by merging with the main line of development. 
Although a large number of commits cleanly merge, parallel changes can overlap, leading to merge conflicts. Kasi et al.~\cite{cassandra} and Brun et al.~\cite{Brun2011}, in their studies of several open source projects, found that merge conflicts occur in approximately 19\% of all merges.

Resolving merge conflicts is nontrivial, especially when changes diverge significantly, making their synchronization difficult.
The resolution process can be tedious and can cause delays as practitioners figure out how to approach and resolve conflicts~\cite{cassandra}. 
Poorly-performed merge conflict resolutions have been known to cause integration errors~\cite{bird-branches-conflict}, workflow disruptions, and jeopardize project efficiency and timelines~\cite{estler2014awareness}. 

Practitioners are aware of the merge-resolution ``pains" and follow different informal processes to avoid having to resolve conflicts; e.g. sending out emails to the rest of the team, performing partial commits, or racing to finish changes \cite{deSouza2003breaking}\cite{cataldo2008distributed_dev}.
Unfortunately, these practices cause changes to diverge more and makes merge conflict resolution even harder~\cite{Brun2011}. 

Past work has examined different mechanisms for proactive conflict detection~\cite{Brun2011}\cite{palantir}\cite{Guimaraes}, proposed tools for resolving merge conflicts~\cite{nishimura}\cite{mens2002state}, and discussed advantages of syntax- and semantic-aware merges \cite{danny_refactorings}\cite{hunt2002extensible}. 
However, there are several key questions that remain unanswered: How do practitioners actually approach merge conflicts? How do practitioners perceive the difficulty of a merge conflict resolution? Do the current tools support practitioners' conflict resolution needs?
Without such knowledge, tool builders might be building on wrong assumptions and researchers might miss opportunities for improving the state of the art.

To answer the above key questions, we talked directly to practitioners, which is crucial to understanding problems in context~\cite{fritz2010using, sillito2006questions, de2008answering, ko2007information}.
We interviewed 10 software practitioners from 7 organizations about their experiences and perceptions of merge conflicts in the software development process.
Our participants had a median of 5 years of software development experience, and work on a mix of both small-scale projects ($<$10 contributors) and large-scale projects ($>$1000 contributors).
These interviews helped us understand how practitioners approach merge conflicts, and their unmet needs.

To triangulate our findings and provide a broader understanding of practitioners' perceptions of merge conflicts and their difficulty, we deployed a survey to a larger population of software practitioners.
The survey sampled 162 participants, spanning both open source and commercial projects. 74.2\% of our participants had 6 or more years of software development experience, and reported that they face merge conflicts a few times a week.
%most frequently report encountering merge conflicts a few times a week. Participants spanned both open source and commercial projects.
%The interviews provide the basis for the survey, as well giving us personal accounts of merge conflicts.
%The survey provides a broader understanding of how perceptions permeate the larger software development community.

To understand the effects and implications of software practitioner perceptions, we answer the following research questions:

\begin{itemize}
\item \textbf{RQ1:} \textit{How do software practitioners approach merge conflicts?}
\item \textbf{RQ2:} \textit{What unmet needs impact the difficulty of a merge conflict resolution?}
\item \textbf{RQ3:} \textit{How well do tools meet practitioner needs for merge conflicts?}
\end{itemize}

We found that practitioners, when initially assessing a merge conflict, focus on the \textit{code complexity of the conflicting lines} and \textit{their own knowledge in the area of the conflict} as the top two factors when estimating the difficulty of a conflict. These concerns cause practitioners to alter their resolution strategy, and in some cases delay resolution.

After understanding the merge conflict, practitioners must resolve the conflict in order to return to normal development.
We found that the key challenges that practitioners face when resolving conflicts is \textit{understanding the conflicting code}, \textit{their knowledge in the area of code conflict}, and having enough meta information about the conflicting code (who made the change, why, etc).

We found that development tools struggle to address practitioners' perceptions that increases in merge conflict complexity have a greater impact on the conflict difficulty  than increases in size.
This could partially be alleviated by focusing on the tool improvements most desired by practitioners: \textit{better usability}, \textit{better information filtering}, and \textit{better history exploration}.

%In the context of these findings, we present implications for researchers, tool builders, and practitioners.
%For example, researchers have previously developed merge conflict avoidance and resolution tools that need to be simplified and brought into alignment with the basic merging tools used by software practitioners.
%Tool builders should create merging tools that provide more context-sensitive information about conflicting code, and do so when scaling to more complex merge conflicts.

This paper makes the following contributions:
\begin{itemize}
\item We conduct exploratory semi-structured interviews with 10 software practitioners, then confirm these findings with a survey of 162 practitioners from around the world.
\item We provide empirically-derived rankings of merge conflict difficulties based on practitioners' perceptions.
\item We expose disparities between practitioners' merge conflict needs and development toolsets.
%\item We present actionable implications that researchers, tool builders, and practitioners can build upon.
\end{itemize}