liveBook · Manning

Merge conflict

As explained in Building User-Friendly DSLs

A condition in which concurrent changes cannot be automatically combined by a version-control system.

A merge conflict occurs when a distributed version-control system cannot automatically consolidate concurrent changes to the same code. A developer must resolve the conflicting changes manually, a situation often called “merge hell.” section 10.1

Merge conflicts arise within a distributed, branch-based change workflow:

  • Contributors branch from a mainline, record changes through commits, and later merge completed work back into the mainline. section 10.1
  • Merging becomes difficult when the branch has accumulated changes while the mainline has changed independently. section 10.1
  • The conflict remains for a developer to reconcile because the version-control system cannot determine how to combine the changes. section 10.1
Figure 10.2 The main concepts of a DVCS, and a typical interaction
figure

Use the distributed version-control interaction diagram to trace branching, commits, sharing, review, and merging around the point where conflicts can occur. section 10.1

How Building User-Friendly DSLs covers it

How deep it goes
Defines the condition, explains branch divergence as its cause, and stops short of detailing resolution procedures.
Examples
Uses concurrent code changes, an independently changed mainline, and the developer experience called “merge hell.”
What it assumes
Assumes familiarity with distributed version control, branches, commits, and mainline merging.
What you can do after
Diagnose why a merge requires manual intervention when concurrent branch and mainline changes cannot be consolidated automatically.
How it connects
Links distributed version control, Git, branches, commits, mainlines, and real-time collaborative editing.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building User-Friendly DSLs. The section links point to the parts of the book it draws on.