Phase 1: Programming & Fundamentals

Merge conflict resolution

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you and a friend are making a super cool comic book together. To get it done faster, you each make a copy of the story and start drawing different pages at the same time. You might be drawing the superhero's amazing new costume, while your friend is adding a giant monster to a different scene. When you both finish, you want to combine your drawings into one awesome, complete comic book. Usually, this works perfectly! You add your finished pages, your friend adds theirs, and poof – a combined, finished comic.

But sometimes, a funny thing happens. What if you and your friend both decided to draw on the exact same part of the same page at the same time? For example, you both want to draw the superhero's face on page 5. You draw a big, cheerful smile, and your friend draws a serious, determined look. When you try to put page 5 from your version and page 5 from your friend's version into the main comic book, it's impossible! The comic can't have two different faces on the superhero at the same moment. The comic book gets confused and essentially says, "Whoa, hold on! I don't know which face you want!" In coding, we call this a "merge conflict" – it's when the computer sees two different changes in the exact same spot and can't figure out which one is the right one.

When this "face-off" happens in your comic book, you'd open up page 5 and see both drawings of the face right there. You'd see your smiling face and your friend's serious face, side-by-side. The comic book needs you to be the editor. You have to look at both and decide: Do you want the smiling superhero? The serious superhero? Or maybe you talk to your friend and decide to draw a brand new face that combines both ideas, like a half-smile that's both cheerful and determined? You pick one, or you create a whole new drawing that makes the most sense for the story.

Once you've made your decision and drawn the final, perfect superhero face on page 5, you simply erase the parts you don't want, so only one clear drawing remains. Then, you tell the comic book, "Okay, I fixed this page! This is the one we want." In coding, when you resolve a conflict, you're doing the same thing: you're telling the computer, "I've looked at all the different ideas for this spot, and I've chosen the final version." After you've gone through all the pages where you both drew in the same spot and made a final decision for each, your entire comic book (or your code project) can finally be put together, clean and complete, just the way you intended. This skill is super useful! It means that even when many people are working on the same big project, like building a video game or a website, everyone can still work on their own parts without always waiting for others. You become the "editor" who can make sure all the different ideas fit together perfectly into one amazing final creation. So, when you build awesome apps or games in the future, you'll be able to work smoothly with a whole team of friends, making your projects even bigger and better!

Imagine you're working on a feature branch, and at the same time, a colleague is working on a different feature (or even a bug fix) on another branch. Eventually, you'll want to combine these changes, often into a main or develop branch. This process is called merging. A "merge conflict" occurs when Git can't automatically figure out how to combine changes from two different branches. This typically happens when both branches have modified the same lines in the same file, or if one branch deleted a file that the other modified. Git is smart, but it can't read minds to know which change is the "correct" one, so it asks you to decide.

When a merge conflict happens, Git will pause the merge and tell you which files have conflicts. If you open a conflicted file, you'll see special markers that Git inserts to highlight the problem areas. <<<<<<< HEAD indicates the changes from your current branch (often HEAD refers to the branch you are currently on and trying to merge into). ======= acts as a separator between the conflicting changes. >>>>>>> branch-name indicates the changes from the branch you are trying to merge from. Your task is to manually edit the file, deciding which version of the code to keep – your changes, their changes, or a combination of both – and then remove these markers.

Resolving a conflict is a hands-on process. First, identify the conflicted files (using git status). Then, open each file in your code editor. Carefully examine the code between the <<<<<<<, =======, and >>>>>>> markers. You'll need to choose which code block to keep, or modify it to incorporate elements from both, ensuring the final code is correct and functional. Once you've made your decision, delete all the conflict markers (the <<<<<<<, =======, >>>>>>> lines). After saving the modified file, you must tell Git that the conflict is resolved by running git add <conflicted-file>. Repeat for all conflicted files. Finally, complete the merge by running git commit -m "Resolve merge conflict". This creates a new commit that incorporates all the merged changes, including your conflict resolution.

Key Takeaways

  • Merge conflicts occur when Git can't automatically combine changes, usually affecting the same lines in the same file.
  • Git uses <<<<<<< HEAD, =======, and >>>>>>> branch-name markers to highlight conflicting sections in files.
  • To resolve, manually edit the file, choose the desired code, and remove all conflict markers.
  • After editing, git add <file> the resolved files and then git commit to complete the merge.
  • Resolving conflicts is a normal, everyday part of collaborative software development.

Code Example

javascript
Preview

How this code works

This code example illustrates a JavaScript file, app.js, caught in a Git merge conflict. Its job is to show precisely how Git marks the points of disagreement when two branches, in this case, the current branch (HEAD) and a feature branch (feature/new-greeting), have both made different changes to the same lines of code within the greet function. The file is presented in the state it would be in immediately after Git tried to merge and failed automatically, leaving the conflict for manual resolution.

Git uses special markers to highlight the conflicting sections. The lines between <<<<<<< HEAD and ======= represent the version of the greet function from the branch that was checked out (the current branch). Below the ======= marker, the lines up to >>>>>>> feature/new-greeting show the alternative version of the greet function from the branch being merged into the current one. A subtle but crucial point for beginners is that these <<<<<<<, =======, and >>>>>>> markers are not valid JavaScript syntax. If this file were run directly, it would result in a syntax error; they are solely Git's way of pointing out what needs to be fixed. The greet('World') call remains unaffected as it was not part of the conflicting changes.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Backend Developer Roadmap