# Merge Conflict
An event that occurs when a version control system is unable to automatically reconcile differences in code between two branches being merged, requiring manual intervention.
**Pronunciation:** murj kon-flikt
**Difficulty:** Beginner
**Synonyms:** Merge Collision
**Categories:** Version Control, Software Development
**Tags:** Git, VCS, Collaboration, Branching, Merging
Canonical: https://scaleengineer.com/glossaries/merge-conflict
---
## Definitions

- **Merge Conflict in Version Control Systems:** A **merge conflict** occurs in a version control system (VCS) like Git when it is unable to automatically resolve differences in code between two branches that are being merged. This situation typically arises when two developers have made changes to the same lines in the same file, or when one developer edits a file and another developer deletes the same file.

### Key Concepts

*   **Automatic vs. Manual Merge**: A VCS can automatically merge changes when they occur in different parts of a file. A conflict happens when the changes overlap, requiring human intervention.
*   **Conflict Markers**: When a conflict occurs, the VCS will pause the merge process and mark the conflicting areas in the file with special markers. In Git, these markers are:
    *   `<<<<<<< HEAD`: This indicates the beginning of the conflicting lines from your current branch (the one you are merging into).
    *   `=======`: This separates the conflicting changes.
    *   `>>>>>>> [branch-name]`: This indicates the end of the conflicting lines from the branch you are merging in.

### Example of a Conflict

Imagine the `main` branch has a file `style.css` with:

```css
body {
  color: black;
}
```

You create a branch `feature-a` and change the color to `blue`. Another developer creates `feature-b` and changes the same line to `red`. When you try to merge `feature-b` into `feature-a`, Git cannot decide which color to use and will produce a conflict:

```css
body {
<<<<<<< HEAD
  color: blue;
=======
  color: red;
>>>>>>> feature-b
}
```

### Resolving the Conflict

To resolve the conflict, a developer must:
1.  Open the file containing the conflict markers.
2.  Manually edit the file to remove the markers and decide what the final version should look like. This could mean keeping one version, the other, or a combination of both.
3.  Save the file.
4.  Stage the newly resolved file using the `git add` command.
5.  Commit the merge to finalize the resolution.

Many IDEs and dedicated merge tools (like VS Code, Sublime Merge, or Beyond Compare) provide a graphical interface to make this process easier, often showing the changes side-by-side.

## Etymology

The term is a compound of 'merge' and 'conflict'. 'Merge' refers to the action of combining or uniting, originating from the Latin 'mergere' (to dip, plunge). 'Conflict' comes from the Latin 'conflictus', meaning 'a striking together, a contest'. In the context of version control, it literally means a 'clash during a combination' of code branches.

## First used

1980s

## Historical context

The concept of a **merge conflict** is intrinsically linked to the evolution of Version Control Systems (VCS). 

In the early days of version control with systems like SCCS (Source Code Control System, 1972) and RCS (Revision Control System, early 1980s), collaboration was often managed through a lock-based model. A developer would 'lock' a file to edit it, preventing others from making changes simultaneously. This model avoided conflicts but created bottlenecks.

The next generation of VCS, known as Centralized Version Control Systems (CVCS), introduced a more collaborative model. CVS (Concurrent Versions System, late 1980s) allowed multiple developers to work on the same files at the same time. When they checked their work back into the central server, the system would attempt to merge the changes. This is where the concept of a **merge conflict** became a common, and often frustrating, part of a developer's workflow. Subversion (SVN, 2000) improved upon CVS but retained the same fundamental centralized model and conflict potential.

The paradigm shifted significantly with the rise of Distributed Version Control Systems (DVCS) like Git (2005) and Mercurial (2005). In a DVCS, every developer has a full copy of the repository's history. Branching and merging became cheap, fast, and central to the workflow, rather than an occasional event. This made dealing with **merge conflicts** a more frequent and essential skill for modern software developers. Tooling around conflict resolution has also matured, with IDEs and dedicated merge tools providing sophisticated UIs to simplify the process.

## Q&A

- **What is the primary cause of a merge conflict?:** A merge conflict occurs when two or more developers make competing changes to the same line(s) of a file in different branches, and the version control system cannot automatically decide which change to keep.
- **What do the `<<<<<<< HEAD`, `=======`, and `>>>>>>> [branch-name]` markers in a file indicate?:** These are conflict markers inserted by Git. The code between `<<<<<<< HEAD` and `=======` represents the changes from the current branch (your changes), while the code between `=======` and `>>>>>>> [branch-name]` represents the changes from the branch you are trying to merge in (incoming changes).
- **After manually editing a file to resolve a merge conflict, what is the next step in Git?:** After editing the file to remove the conflict markers and create the final desired version, you must stage the resolved file using `git add <filename>` and then complete the merge with `git commit`.

## Usage examples

- Our deployment was delayed because a developer introduced a major **merge conflict** that took hours to resolve.
- When Git reported a **merge conflict**, I had to manually edit the file to choose which lines of code to keep from my branch and the main branch.
- To avoid a potential **merge collision**, it's good practice to pull the latest changes from the remote repository before pushing your own.

## Related terms

- Git
- Branch
- Merge
- Rebase
- Pull Request
- Version Control System
- Diff
- Patch

## Popular related terms

- Git
- Branch
- Merge
- Rebase
- Pull Request