What a merge conflict is and why it happens
A merge conflict occurs when two people edit the same lines in the same file and then try to combine their work. Git cannot automatically decide which version to keep, so it stops and asks you to choose. This is actually Git protecting you — it is forcing you to make a deliberate decision instead of silently losing someone's work.
The most common scenario: you and a colleague both pull the same file from the shared repository. You change line 15. They change line 15 differently. You push your change first. When they try to push, Git says "I cannot merge these — you need to decide which version of line 15 is correct." Until you resolve it, that merge stays incomplete and blocks the repository.
Conflicts are not a sign of failure. They are a normal part of teamwork on code. The size of your team and the number of people editing the same files determine how often you see them. A two-person team working on separate features might see one a month. A ten-person team all editing the same configuration file might see several a day.
Key Takeaways
- A merge conflict happens when two people change the same lines in the same file, and Git cannot automatically decide which version to keep.
- Git marks the conflicting section with clear labels so you can see both versions side by side and choose which one to keep.
- You resolve the conflict by editing the file directly, removing the conflict markers, and then completing the merge with a commit.
- The fastest way to avoid conflicts is to keep changes in separate files and merge frequently, so conflicts stay small when they do happen.
- If a conflict is too tangled to resolve yourself, you can abort the merge and ask the other person to help you decide.
How to spot a merge conflict in your editor
When you try to merge and Git finds a conflict, it stops the merge and marks the problem directly in the file. Open the conflicted file in your editor and look for this pattern:
<<<<<<< HEAD your version of the code ======= their version of the code >>>>>>> branch-name
The section between <<<<<<< HEAD and ======= is your version (the one you are currently on). The section between ======= and >>>>>>> is the version from the branch you are trying to merge in. The markers themselves are not part of your actual code — they are Git's way of showing you the problem.
A single file can have multiple conflicts if different sections were edited by different people. Each conflict gets its own set of markers. Your editor may also highlight these sections in color to make them easier to spot.
The three ways to resolve a conflict
Once you see the conflict markers, you have three choices: keep your version, keep their version, or combine both versions into something new.
Keep your version: Delete the entire conflict section and the markers, leaving only the code between <<<<<<< HEAD and =======. This tells Git "use what I had." Use this when you know their change was wrong or outdated.
Keep their version: Delete the entire conflict section and the markers, leaving only the code between ======= and >>>>>>>. This tells Git "use what they had." Use this when their change is better or more recent than yours.
Combine both versions: Edit the section to include parts of both versions, then delete the conflict markers. This is the most common resolution when both changes are valid but need to coexist. For example, if you added a new function and they added a new import statement, you keep both. Delete the markers and make sure the combined code makes sense.
After you choose, save the file. The conflict markers must be completely gone — Git will not accept a merge that still contains <<<<<<< or ======= or >>>>>>>.
How to complete the merge after resolving conflicts
Once you have edited the file and removed all conflict markers, you need to tell Git that the conflict is resolved. The process depends on whether you are using the command line or a graphical tool.
On the command line: Stage the resolved file with git add filename, then complete the merge with git commit. Git will open your editor to write a merge commit message. You can accept the default message or write your own. The commit message should mention what the conflict was and why you resolved it the way you did — this helps your team understand your decision later.
In a graphical tool: Most Git interfaces (GitHub Desktop, GitKraken, VS Code's built-in Git tools) have a button to mark the file as resolved. Click it, then click the merge button to complete the merge. The tool will create the merge commit for you.
After the merge completes, test the code to make sure it still works. A conflict resolution that compiles is not the same as one that actually functions. Run your tests, check the behavior, and push only after you are confident the merge is correct.
How to prevent conflicts before they happen
The best conflict is the one you never have. While you cannot eliminate conflicts entirely in a team, you can make them rarer and smaller.
Keep changes in separate files: If two people need to edit the same repository, try to have them work on different files. A configuration file that everyone touches will generate conflicts constantly. A system where each person edits their own feature file will not.
Merge frequently: The longer you wait to merge, the more changes pile up and the bigger conflicts become. If you merge every day, conflicts stay small and straightforward to resolve. If you merge every month, a single conflict might involve hundreds of lines.
Communicate before you start: If you know someone else is working on the same file, talk to them first. Decide who changes what, or take turns. Five minutes of conversation prevents an hour of conflict resolution.
Pull before you push: Always pull the latest version from the shared repository before you push your changes. This catches conflicts early, when they are still fresh in your mind and the other person is still available to discuss them.
What to do if a conflict is too complicated to resolve alone
Sometimes a conflict involves logic that is too tangled for one person to untangle safely. The code might depend on changes you do not fully understand, or the two versions might be so different that combining them requires architectural decisions.
In this case, abort the merge and ask for help. On the command line, type git merge --abort. This cancels the entire merge and returns your repository to the state it was in before you started. No changes are lost — you just go back to where you were.
Then contact the person who made the other change. Explain what the conflict is, show them the two versions, and work together to decide what the correct code should be. One of you can then resolve the conflict with both people present, or one person can resolve it and the other can review it before it is pushed.
This is not a failure. It is the correct way to handle a conflict that requires judgment calls or architectural knowledge. Pushing a broken merge just to avoid asking for help is far worse.
Frequently Asked Questions
Can I undo a merge after I have already resolved the conflict and pushed it?
Yes, but it is disruptive. You can use git revert to create a new commit that undoes the merge, or git reset to go back to before the merge happened. Both require everyone else to pull the new state. It is better to catch merge problems before you push, which is why testing after a conflict resolution matters.
What if I resolve a conflict wrong and do not realize it until later?
The broken code will usually show up in testing or in the next person who pulls and runs the code. When it does, you can fix it in a new commit. Document what was wrong in the commit message so the team knows what happened. This is normal and not a serious problem.
Do I have to resolve conflicts on the command line, or can I use my editor?
Most modern editors have built-in conflict resolution tools. VS Code, for example, shows a visual interface with buttons to choose "Accept Current Change", "Accept Incoming Change", or "Accept Both Changes". These tools do the same thing as manual editing — they just make it easier to see and click. Use whatever is fastest for you.
What if the same file has conflicts every single time we merge?
This is a sign that the file is too central and too many people are editing it. Consider splitting it into smaller files, each owned by one person or team. Or establish a rule that only one person edits that file at a time, and others request changes through code review instead of pushing directly.
Can Git automatically resolve conflicts for me?
Git has a few automatic strategies, but they are risky. The default is to stop and ask you, which is the safe choice. You can configure Git to prefer one version over another in certain situations, but this only works for straightforward cases and can hide real problems. It is better to resolve conflicts manually and understand what you are keeping.