Merge Conflict

Many people work simultaneously on larger software projects. So that no one overwrites anyone else’s work, everyone gets their own copy of the files. Later, these copies are merged back together into a shared version. Most of the time this works automatically, because the changes are in different places. But if two people have changed exactly the same line in different ways, the program cannot decide which version is correct. It reports a merge conflict and requires a human to resolve the spot by hand.

Why teams constantly deal with this

Merge conflicts are not a sign that someone made a mistake. They are the normal price of allowing several people to work in parallel. The alternative would be that only one person is ever allowed to write to a file at a time. That would slow a team of twenty developers to a hopeless crawl.

Conflicts are dangerous nonetheless, because they occur at a delicate spot. Anyone who resolves them carelessly can delete someone else’s code without noticing. Afterward, the file looks clean, but an important line is missing. Such mistakes often only come to light weeks later. That is why resolving conflicts is one of the tasks experienced developers look at especially closely.

The longer someone works on their own copy, the bigger the conflict becomes in the end. After three days it might be two lines. After three months it’s hundreds, and no one remembers anymore why a particular change was necessary. For this reason, many teams prefer to merge their work daily rather than once a quarter.

What the program reports and what the human has to do

The most widespread tool for this work is called Git. It is a so-called version control system, that is, a program that records every change to every file along with the time and the author. When merging, Git compares three versions: the common starting version and the two altered copies. Wherever only one side has changed something, Git adopts the change silently.

It only becomes a problem where both sides have touched the same spot. Git then writes both variants one below the other into the file and marks them with conspicuous character sequences. On top is one’s own version, below it the other person’s. In this state, the file is not runnable — it is deliberately broken. That forces someone to take a look.

The human now decides: keep one of the two variants, or build a third one out of both. Often the third option is correct, because both changes made sense. A typical mistake is simply taking the newer version. Newer does not mean better, and anyone who doesn’t understand the other person’s code is better off asking. Afterward, the markers are removed and the merged version is saved.

From school projects to AI tools

You encounter this principle everywhere multiple people work on the same text. Anyone who has ever co-written a paper with someone else and had to glue two versions together knows the problem. In word processors, the function is called tracking changes; in software development, it’s simply called a merge. GitHub, the platform hosting millions of projects, displays conflicts directly in the browser.

In the news, the term has been coming up for some time now in connection with AI. Programming assistants now write huge amounts of code, often on several tasks at once. This creates more parallel working states than before, and thus more conflicts as well. Some tools are therefore trying to automatically resolve simple conflicts.

So far, this is not reliable. An AI can suggest which version looks sensible, but it does not know the intent behind a change. Responsibility for the outcome remains with the team. Merge conflicts are thus a good example of how technical tools can prepare decisions but cannot take them off human hands.