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

Software development has always been a collaborative enterprise, and the challenge of merging work from multiple contributors dates back to the earliest shared computing environments. In the 1970s and 1980s, programmers working on large C and C++ codebases frequently encountered situations where two people modified the same file simultaneously, leading to lost work or subtle bugs that went undetected for weeks. Early version control systems (VCS) such as SCCS and RCS addressed this by implementing exclusive file locking — only one developer could edit a file at a time. While this prevented conflicts entirely, it severely limited parallel productivity on large projects.

The introduction of CVS in the late 1980s pioneered the optimistic concurrency model: multiple developers could edit the same file concurrently, and the system would attempt to merge changes automatically. When the automatic merge failed — typically because two developers modified the same lines — a merge conflict was reported, and the developer was responsible for resolving it manually. This model proved so successful that it carried forward through Subversion, Mercurial, and ultimately Git, which Linus Torvalds created in 2005 to manage the Linux kernel — a massive C codebase with thousands of contributors.

Today, merge conflicts are an unavoidable part of collaborative C++ development. Whether you are working on a class project with a teammate or contributing to an open-source library, the question is not if you will encounter a conflict, but when. Understanding what causes these conflicts and how to resolve them cleanly is a foundational skill in professional software engineering.

A merge conflict occurs when Git's automatic merge algorithm encounters competing changes to the same region of a file on two different branches. Git performs a three-way merge by comparing each branch's version of the file against the common ancestor — the version that existed before the branches diverged. When both branches modify the same lines relative to the ancestor, Git cannot determine which change the developer intends to keep, so it halts and marks the file as conflicted. Understanding this three-way comparison is the key to understanding why conflicts arise and how to resolve them.

The following diagram illustrates the branching and merging process that leads to a conflict. Two branches, main and feature, diverge from a common ancestor commit. Both branches modify overlapping lines in the same file, which produces a conflict when the developer attempts to merge feature into main.

In the diagram above, commit A is the common ancestor containing int x = 10;. The cyan path represents the main branch (commits B and C), which changes the value to 20. The pink path represents the feature branch (commits D and E), which changes the value to 42. When Git attempts the merge, it detects that the same line was changed differently in both branches relative to A, producing the conflict shown in the red box. The three conflict markers — <<<<<<<, =======, and >>>>>>> — are the textual structures you must understand to resolve the conflict.

Git's merge algorithm operates at the granularity of text hunks — contiguous groups of lines that differ between versions. When you run git merge feature while on main, Git identifies the merge base (common ancestor), then computes two diffs: base→main and base→feature. If a hunk is changed in only one diff, Git applies that change automatically. If the same hunk is changed in both diffs but in different ways, Git declares a conflict. This is fundamentally a line-based diff comparison, which is why conflicts are particularly common in C++ header files where multiple developers may add #include directives or modify class declarations in the same region.

Anatomy of a Conflict-Marked File

When a conflict is detected, Git writes a modified version of the file to your working directory. The conflicted region is delimited by three markers, each on its own line. The structure is precise: <<<<<<< HEAD marks the beginning of your current branch's version (the branch you are on when you issue the merge command). The ======= separator divides the two versions. Below it is the incoming branch's version, terminated by >>>>>>> feature (where "feature" is replaced by the actual branch name or commit hash).

The Resolution Workflow

1. Detect: Run git merge <branch>. Git reports CONFLICT (content): Merge conflict in <file> and sets the merge state to "in progress."
2. Inspect: Open the conflicted file in your editor. Search for <<<<<<< to locate each conflict region. A single file may contain multiple conflict regions.
3. Edit: Decide on the correct resolution — keep one side, combine both, or write a new version. Delete all three conflict markers entirely.
4. Stage: Run git add <file> to mark the conflict as resolved for that file.
5. Commit: Run git commit to finalize the merge commit. Git pre-populates the commit message with merge details.

Merge conflicts in C++ files tend to occur in predictable locations. Header files with #include blocks are frequent conflict sites because multiple developers often add new includes in the same alphabetically-sorted region. Class declarations are another hotspot, especially when two developers add new member functions or modify constructor signatures. Understanding the typical conflict patterns helps you resolve them faster and with greater confidence.

The diagram highlights the critical detail: lines outside the conflict markers are not in dispute. Lines 1–4 and the closing brace are identical in both branches relative to the ancestor, so Git merges them without issue. Only line 5 — the return statement — differs between the two branches. In the resolved version at the bottom, the developer decided that the correct behavior requires both operations, so they wrote a new expression that incorporates the logic from both branches. This is a common pattern: the resolution is often neither "ours" nor "theirs" but a thoughtful synthesis.

Suppose you and a partner are building a C++ project. You are on the main branch, and your partner's work is on a branch called add-logging. Both of you have modified the greet function in utils.cpp. You run git merge add-logging and Git reports a conflict.

Not all merge conflicts require the same resolution approach. Git provides several strategies and tools, each suited to different situations. The table below compares the most common approaches for resolving conflicts in C++ projects, along with their strengths and limitations.

The simple text-file conflicts covered in this lesson form the foundation for more sophisticated merge scenarios you will encounter in professional C++ projects. As codebases scale — think the Linux kernel with its 30+ million lines of C/C++ — developers employ advanced strategies like rebasing, cherry-picking, and interactive staging that all build on the same conflict resolution mechanics you have just learned.

An important nuance to keep in mind is that git rebase replays your commits on top of the target branch one at a time, so you may encounter sequential conflicts — one for each commit that touches the same lines. The resolution process for each individual conflict is identical to what you have practiced here, but the overall workflow requires additional commands (git rebase --continue, git rebase --abort). Mastering simple merge conflicts now will make these advanced scenarios straightforward when you encounter them.