Resolving Merge Conflicts — Resolve simple merge conflicts in text files (intro)

Before modern version control systems existed, programmers working on the same codebase had to coordinate manually. They might email files back and forth, keep numbered copies on a shared drive, or simply shout across the room, "Don't touch main.py right now!" As software projects grew to involve dozens or even thousands of contributors, this approach became completely unworkable. The need for a system that could automatically merge changes from different people became critical.

Version control tools like Git solved most of this problem by tracking every change and automatically combining work from different branches. However, when two people edit the exact same lines of a file, Git cannot decide whose version to keep. This situation is called a merge conflict, and it requires a human to step in and resolve it.

Today, understanding how to read and resolve merge conflicts is as fundamental as writing code itself. Whether you are collaborating on a school project or contributing to open-source software, you will encounter merge conflicts. The key question is: how do you read the conflict markers Git places in your files, and how do you decide what the final code should look like?

Before you can resolve a merge conflict, you need to understand a few foundational ideas about how Git tracks and combines changes. These concepts form the mental model you will rely on every time you see those intimidating conflict markers in a file.

The diagram below shows exactly what happens inside a file when Git encounters a merge conflict. Understanding this visual layout is the single most important step toward confidently resolving conflicts.

Notice three critical markers in the conflict zone. The <<<<<<< HEAD line marks the beginning and tells you everything between it and the divider is from your current branch. The ======= divider separates the two competing versions. Finally, >>>>>>> feature-welcome marks the end and names the incoming branch. Everything outside these markers is code that both branches agreed on, so Git left it alone.

Git does not simply compare two files against each other. It uses a technique called a three-way merge. When you merge branch B into branch A, Git finds the common ancestor — the commit where the two branches originally diverged. Git then compares each branch's file to this ancestor to determine what changed.

If branch A changed line 5 but branch B did not, Git keeps branch A's version of line 5. If branch B changed line 10 but branch A did not, Git keeps branch B's version. These are clean merges — Git handles them automatically. A conflict only arises when both branches changed the same line relative to the ancestor, because Git cannot guess which change you intended.

When you open a file with a merge conflict, the conflict markers may look intimidating at first. However, they follow a strict, predictable pattern. Once you learn to read them, resolving conflicts becomes a straightforward process. Let's break down each marker and its role.

A single file can contain multiple conflict zones if different sections of the same file were edited by both branches. Each conflict zone has its own set of three markers. You must resolve every conflict zone before Git considers the merge complete.

• Option A — Keep yours: Delete the incoming section, the divider, and all three markers. Keep only the code between <<<<<<< and =======.
• Option B — Keep theirs: Delete your section, the divider, and all three markers. Keep only the code between ======= and >>>>>>>.
• Option C — Combine both: Manually edit the section to include the best parts of both versions, then delete all three markers.
• Option D — Rewrite: Replace the entire conflict zone with completely new code, then delete all three markers.

Let's walk through a complete scenario. You and your classmate are both working on a Python project. You are on the main branch, and your classmate worked on a branch called feature-greeting. When you run git merge feature-greeting, Git reports a conflict in greeting.py.

There is no single "correct" way to resolve every merge conflict. Your strategy depends on the context: what the code does, who wrote it, and what the project needs. Here is a comparison of common approaches.

The simple text-based conflict resolution you have learned here is the foundation for more advanced Git workflows used in professional software development. As projects grow, teams adopt strategies like rebasing, cherry-picking, and pull request reviews that all build on your ability to read and resolve conflicts.

As you gain experience, you will also learn to prevent many merge conflicts before they happen. Strategies like keeping branches short-lived, merging frequently from main, and communicating with teammates about which files you are working on can dramatically reduce the number of conflicts you encounter.