# Merge conflict

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/merge-conflict

## Quick definition

A merge conflict happens when two people change the same line of a file at the same time, and the version control system doesn't know which change to keep. It's like two editors both rewriting the same sentence in a document and the program asking you to decide. You have to manually pick the correct version or combine the changes. This is a normal part of working with tools like Git in a team.

## Simple meaning

Imagine you and your friend are both editing the same paragraph of a shared Google Doc. You both decide to rewrite the same sentence, but you each write something different. When you both hit save, the document doesn't know which version to show. It gets confused and says, “I see two different changes here, please pick one.” That’s a merge conflict.

In the world of software and IT, version control systems like Git keep track of every change made to files. When several people are working on a project, they each make their own copies, called branches. A branch is like a separate workspace where you can try out new ideas without messing up the main project. When you are ready to combine your changes back into the main workspace, you do a “merge.” Usually, the system can combine changes automatically if they are in different parts of a file. But if two people changed the exact same line of code in different ways, the system cannot decide which one is correct. That is a merge conflict.

Think of it like a traffic jam. Two cars arrive at the same intersection from different directions at the same time. There is no traffic light to tell them who goes first. Someone has to stop and decide. In a merge conflict, you are the traffic cop. You have to look at both changes, decide which one is correct, or merge them into a new solution. Once you resolve the conflict, the traffic flows smoothly again, and the project moves forward.

## Technical definition

A merge conflict occurs in distributed version control systems, most commonly Git, when the automatic merge process fails because two branches have made competing changes to the same section of a file. Git uses a three-way merge algorithm to combine changes. This algorithm compares three versions of a file: the common ancestor (the last version before the branches diverged), the current branch version, and the merging branch version. When the algorithm detects that both branches have modified the same region of a file (typically the same line or adjacent lines), it cannot determine which change should prevail, and it marks the conflict.

When a merge conflict is detected, Git pauses the merge operation. It inserts conflict markers into the affected file to highlight the conflicting sections. These markers are <<<<<<< HEAD (indicating the current branch's version), ======= (separating the two versions), and >>>>>>> branch-name (indicating the incoming branch's version). The developer must then manually edit the file to resolve the conflict by choosing one version, combining them, or writing entirely new code, and then remove the conflict markers. After resolving all conflicts, the developer stages the resolved file and completes the merge commit.

Merge conflicts can also occur due to rename conflicts (when a file is renamed in one branch and modified in another), or when binary files are modified in both branches and cannot be automatically merged. In more complex scenarios, a conflict may arise from structural changes in the code, such as when a function signature is changed in one branch and the function call is modified in another. These conflicts are known as semantic conflicts and are not detected by Git, requiring careful code review. Proper practices to minimize conflicts include frequent merging, small atomic commits, clear communication among team members, and using feature branches with a short lifecycle. Understanding how to resolve merge conflicts is essential for any IT professional using version control in a collaborative environment.

## Real-life example

Think about a group of friends writing a shared story on a whiteboard. Alice starts by writing the first few paragraphs. Bob comes along and adds a new character in the middle. Meanwhile, Carlos deletes the ending and writes a different one. Now, Alice returns and wants to add a twist to the middle paragraph that Bob already changed. The whiteboard now has multiple erasures and scribbles in the same area. It is confusing because you can see both Bob’s and Alice’s ideas on the same lines.

This is exactly what a merge conflict looks like in code. The whiteboard is like the file in your repository. Each friend is a developer working on a branch. When they all try to write their changes back onto the same whiteboard (the main branch), some parts overlap. The whiteboard doesn’t have a magic eraser that knows which version to keep. So the team has to stop, look at the messy area, and decide what the final story should say. Alice, Bob, and Carlos have to talk, erase the messy part, and write a clear combined version that makes sense. That conversation and decision is the “merge conflict resolution.”

In the real world, you might see this when two people update the same line in a configuration file, like setting a server port number. One sets it to 8080, the other to 9090. Git cannot guess which port is correct. A human must look at the context, perhaps check the documentation or ask a teammate, and choose the right port. After that, the merge continues, and the project moves on without the confusion.

## Why it matters

Merge conflicts matter because they are one of the most common and anxiety-inducing experiences for developers and IT professionals working in teams. If you do not understand how to resolve them, you can easily break the codebase, lose someone’s work, or waste hours of time. In a professional environment, the ability to handle merge conflicts calmly and correctly is a sign of maturity. It shows that you understand not just the tool, but the collaborative workflow.

From a practical standpoint, merge conflicts are inevitable. Even the best teams with excellent communication will encounter them. They are not a sign of failure, but rather a natural consequence of parallel work. The key is knowing how to resolve them efficiently. This means being able to read the conflict markers, understand the intent of both changes, and make a decision that preserves the functionality and integrity of the software. In many DevOps practices, continuous integration pipelines will fail if a branch has unresolved conflicts, blocking the deployment process. This can delay releases and frustrate teams.

understanding merge conflicts teaches you about the underlying mechanics of version control. It reinforces concepts like branches, commits, diffs, and the three-way merge. It also encourages good habits like committing often, pulling changes before pushing, and communicating with team members about what you are working on. For IT certification candidates, knowledge of merge conflicts is directly tested in exams like the Git Certified Associate and appears in the context of collaborative workflows in DevOps-related certifications. It is not just a trivia point, but a real-world skill that hiring managers look for.

## Why it matters in exams

Merge conflicts are a core topic in several IT certification exams, particularly those focused on version control, DevOps, and software development. In the Git Certified Associate (GCA) certification, merge conflicts are directly covered under the “Merging and Resolving Conflicts” objective. Candidates are expected to understand what causes a conflict, how to manually resolve it, and how to use tools like git merge, git rebase, and git mergetool. Exam questions often present a scenario where two branches have conflicting changes, and you must choose the correct sequence of commands to resolve the conflict.

In the AWS Certified DevOps Engineer – Professional exam, merge conflicts may appear in the context of CI/CD pipelines and CodeCommit. You might be asked how to handle a failed merge in a pipeline, or how to configure branch policies that prevent direct pushes to the main branch to reduce conflict risk. The Linux Foundation Certified System Administrator (LFCS) exam may touch on merge conflicts when managing configuration files in a team environment. For the Certified Kubernetes Administrator (CKA), while merge conflicts are not directly tested, understanding Git workflows is essential for managing infrastructure as code, which is a common scenario in the exam.

Question types include multiple-choice questions asking about the correct command to start a merge, or the output of git status after a conflict. You might also see scenario-based questions where you have to identify which lines are conflicting based on conflict markers. Some exams, like the GitHub Foundations certification, test your knowledge of GitHub’s conflict resolution interface. You should be comfortable with the theory and also with the practical steps to resolve conflicts from the command line. Being able to explain the three-way merge algorithm and the purpose of each conflict marker is often a point of distinction for high-scoring candidates.

## How it appears in exam questions

In certification exams, merge conflict questions appear in several distinct patterns. The most common is the scenario-based question. For example: “Developer A changes line 10 in file app.js to set a timeout of 3000ms. Developer B changes the same line to 5000ms. Both push their changes and a merge conflict occurs. Which of the following commands should the developer run to see the conflict?” The correct answer might be git status or git diff. You may also be asked to identify the content of the conflict markers from a snippet.

Another pattern involves workflow questions. For instance: “After a failed automatic merge, what is the correct sequence to resolve the conflict?” Options could include editing the file, using git add, and then git commit, versus git merge --abort followed by a fresh merge. You need to know that after resolving conflicts manually, you must stage the file (git add) and then commit the merge. Some questions present a Git log output and ask which commit caused the conflict.

Configuration-related questions may appear less frequently but are still possible. For example: “Which Git configuration option can be set to use a visual diff tool for conflict resolution?” The answer is mergetool. You might also encounter questions about preventing conflicts, such as: “Which branching strategy reduces the likelihood of merge conflicts?” The correct answer is often short-lived feature branches with frequent merges. Troubleshooting scenarios are also common, where you are given an error message and asked to identify the cause. For instance, “error: merge conflict in index.html” and then you must know that you need to open the file and resolve the conflict. These question patterns test both theoretical knowledge and practical command-line proficiency.

## Example scenario

You are working on a team project for an IT certification practice lab. The team is building a simple web application. You and a colleague are both assigned to update the same configuration file called config.json. Your task is to change the database port from 3306 to 5432. Your colleague’s task is to change the application name from “App” to “MyApp”. However, due to a miscommunication, both of you end up editing the same line in the file that contains the application name. You change it to “TeamApp”, and your colleague changes it to “MyApp”.

You finish your work first, commit your changes to a branch called feature-db-port, and push it. Your colleague commits their changes to a branch called feature-app-name and pushes it. Later, you are told to merge both branches into the main branch. When you try to merge feature-app-name into main, Git reports a merge conflict in config.json. You open the file and see the conflict markers. The HEAD section shows “TeamApp”, and the incoming branch shows “MyApp”. You realize the conflict is over the application name line.

To resolve this, you check with your team lead, who tells you the correct name is “MyApp”. You manually edit the file, remove the conflict markers, and keep “MyApp”. Then you stage the file with git add config.json and complete the merge with git commit. After that, you successfully merge your own feature-db-port branch without conflict because it affected a different line. This experience teaches you the importance of communication and the practical steps to resolve a merge conflict. It also demonstrates that merge conflicts are often simple to fix once you understand what happened.

## Common mistakes

- **Mistake:** Running git push after a merge conflict without resolving it first.
  - Why it is wrong: Git will reject the push because the merge is still in progress and the repository has unresolved conflicts. The push will fail, and the remote branch will not be updated.
  - Fix: Always check git status after a merge. If it says 'Unmerged paths,' you must resolve the conflict, stage the file, and commit before pushing.
- **Mistake:** Deleting the entire file when a merge conflict occurs because it seems easier.
  - Why it is wrong: Deleting the file removes all changes from both branches. This loses work and can lead to data loss. It is almost never the correct solution.
  - Fix: Open the file, read the conflict markers carefully, and choose the correct change. If you are unsure, ask a team member. Do not delete the file.
- **Mistake:** Using git merge --abort without understanding the conflict first.
  - Why it is wrong: Aborting discards all the merge progress and returns the branch to its previous state. If the conflict is small, this wastes time and forces you to start over.
  - Fix: Only abort if the conflict is very large and you need to start fresh for a strategic reason. For small conflicts, resolve them manually.
- **Mistake:** Forgetting to stage the resolved file with git add after editing the conflict.
  - Why it is wrong: Git does not recognize the file as resolved until you stage it. If you skip this step and try to commit, Git will still see the conflict as unresolved.
  - Fix: After editing the file to remove conflict markers and keep the correct code, always run git add <filename> to mark it as resolved.
- **Mistake:** Assuming that the version from the current branch (HEAD) is always correct and discarding the incoming changes without review.
  - Why it is wrong: This can introduce bugs or remove critical features from the other branch. Merge conflicts require human judgment to decide which change is better or if both should be combined.
  - Fix: Review both changes carefully. Understand what the other branch intended. If both changes are valid, combine them. Do not automatically favor your own changes.

## Exam trap

{"trap":"Choosing git merge --continue as the command after resolving a merge conflict instead of git commit.","why_learners_choose_it":"Learners might think --continue is a valid Git command because it sounds logical and is used in other contexts like git rebase --continue. They may also confuse it with the --continue flag in git merge.","how_to_avoid_it":"Remember that after a conflict is resolved, the standard workflow is to stage the resolved files with git add and then run git commit. There is no git merge --continue command. For git rebase, --continue exists, but not for merge. Always use git status to confirm the next step."}

## Commonly confused with

- **Merge conflict vs Git rebase conflict:** A merge conflict occurs during a merge between two branches, while a rebase conflict occurs when you are rebasing a branch onto another. In a rebase, Git replays your commits one by one onto the target branch, which can cause conflicts for each commit, not just once. The resolution process is similar, but you have to resolve conflicts for each commit in sequence. (Example: If you rebase a branch with three commits onto main, you might get a conflict on the first commit, fix it, then get another conflict on the second commit. With a merge, you only get one conflict regardless of the number of commits.)
- **Merge conflict vs Merge commit:** A merge commit is a special commit that joins two branches after a successful merge. It has two parent commits. A merge conflict is the situation that occurs when the merge cannot be completed automatically. You resolve the conflict and then create the merge commit. The conflict is the problem, and the merge commit is the solution. (Example: After you fix a merge conflict in a file, you run git commit. That commit is the merge commit. So the conflict happened before the merge commit existed.)
- **Merge conflict vs Conflict marker:** Conflict markers are the visual indicators that Git places inside a file when a merge conflict occurs. They show the conflicting sections from both branches. The merge conflict itself is the event; the conflict markers are the symptoms. You remove the markers when you resolve the conflict. (Example: When you open a file with a conflict, you see <<<<<<< HEAD, then some lines, then =======, then more lines, then >>>>>>> branch-name. Those lines are conflict markers. The conflict is the underlying disagreement, the markers are what Git uses to show it to you.)
- **Merge conflict vs Fast-forward merge:** A fast-forward merge happens when the branch being merged has no new commits since it diverged from the target branch. It simply moves the pointer forward and does not create a merge commit. A merge conflict only occurs when both branches have diverged with changes that overlap. A fast-forward merge never causes a conflict. (Example: If you work on a branch but main has not changed, merging your branch is a fast-forward, no conflict. If main has also changed in the same file, a merge or conflict may occur.)

## Step-by-step breakdown

1. **Initiate the merge** — You run git merge <branch-name> to combine changes from the specified branch into your current branch. Git checks if a fast-forward merge is possible. If not, it begins the three-way merge algorithm.
2. **Conflict detection** — Git compares the common ancestor, your branch (HEAD), and the merging branch. If it finds that the same part of a file was modified differently in both branches, it pauses the merge and marks the file as conflicted.
3. **File marking and status** — Git inserts conflict markers into the conflicted file. The file will show both versions separated by markers. Running git status will list the file under 'Unmerged paths' to indicate the conflict.
4. **Manual resolution** — You open the file in an editor. You see the conflict markers. You decide which version to keep, combine them, or write new code. You remove the conflict markers and save the file. This step requires human judgment.
5. **Stage the resolved file** — After editing, you run git add <filename> to stage the file. This tells Git that you have resolved the conflict and the file is ready for the next step. Git removes the file from the 'Unmerged paths' list.
6. **Complete the merge** — Once all conflicts are resolved and staged, you run git commit. Git will open a pre-populated merge commit message. You save the message and the merge commit is created, joining the two branches.
7. **Verify the merge** — After the commit, you can run git log to see the new merge commit with two parents. You can also run tests to ensure the merged code works correctly. The merge is now complete.

## Practical mini-lesson

In practice, merge conflicts are a daily reality for IT professionals working with version control. The most important skill is not just knowing the Git commands, but developing a calm and systematic approach to resolving conflicts. When you encounter a conflict, the first step is to understand the context. Run git status to see which files are conflicted. Then run git diff to see the exact lines that are in conflict. This helps you see the changes from both sides without opening the file immediately.

Next, open the conflicted file in a text editor or a merge tool. Many professionals prefer using a visual merge tool like Meld, KDiff3, or the built-in tools in VS Code or IntelliJ. These tools show the two versions side by side and let you pick changes with a click. However, you should also be comfortable manually editing the conflict markers, as you may not always have a GUI available, especially when working on a remote server.

When resolving, think about the intent of both changes. Was one a hotfix that must be preserved? Was the other a refactoring that should take precedence? Use git log for the conflicting branch to see commit messages that explain the changes. If you are uncertain, communicate with the author of the other change. The worst thing you can do is resolve a conflict without understanding it, potentially introducing bugs that are hard to track later.

After resolving, test the code. Run the build, run unit tests, and if possible, run integration tests. A merge conflict resolution that passes tests is a good sign. Finally, push the merge commit to the remote repository. In a professional CI/CD environment, the merge might trigger a pipeline that deploys to a staging environment. Understanding this workflow is crucial for DevOps roles. Professionals often set up branch protection rules that require a successful merge without conflicts before allowing a pull request to be merged. This reduces the frequency of conflicts and ensures that the main branch remains stable.

## Memory tip

Remember 'HEAD is me, incoming is them. Fix the lines, remove the fence, stage and commit, and it all makes sense.'

## FAQ

**Can merge conflicts be prevented entirely?**

No, but they can be minimized by using short-lived branches, communicating with your team, pulling changes frequently, and using rebase to keep your branch up to date with the main branch.

**What happens if I ignore a merge conflict and try to push?**

Git will reject the push because the merge is incomplete. You must resolve the conflict first, stage the file, and commit. Only then can you push.

**Is it safe to use git merge --abort after starting a merge?**

Yes, it is safe. It will abort the merge and return your branch to the state it was in before you started the merge. You will not lose any committed work, but you will lose any changes you made during the merge attempt.

**How do I know which branch’s changes are in the HEAD section of the conflict?**

The HEAD section contains the version from the branch you are currently on (the target branch of the merge). The section after the ======= is from the branch you are merging in.

**Can a merge conflict happen with binary files?**

Yes, if two branches modify the same binary file, Git cannot automatically merge them. The conflict will be reported, and you must choose one version to keep.

**What is a ‘three-way merge’?**

It is the algorithm Git uses to automatically combine changes. It compares the common ancestor of two branches with the two branch tips to determine which changes are unique to each branch and which overlap.

## Summary

Merge conflicts are a normal and expected part of collaborative software development using version control systems like Git. They occur when two branches make incompatible changes to the same part of a file, and Git cannot automatically decide which version to keep. Resolving a merge conflict requires human judgment: you must examine the conflicting changes, choose the correct version or combine them, remove the conflict markers, stage the file, and complete the merge. This process is not a sign of failure but an opportunity to carefully integrate work from multiple contributors.

For IT certification candidates, understanding merge conflicts is essential. Exams like the Git Certified Associate, AWS DevOps Engineer, and GitHub Foundations test your knowledge of conflict detection, resolution steps, and related commands. You should be comfortable with the three-way merge algorithm, conflict markers, and the correct sequence of commands (git merge, git add, git commit). Common mistakes include forgetting to stage resolved files, aborting merges prematurely, and blindly favoring your own changes. By learning to resolve merge conflicts calmly and correctly, you demonstrate practical teamwork skills that are highly valued in the IT industry. This glossary entry has given you the foundational knowledge to handle merge conflicts in both exams and real-world projects.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/merge-conflict