How do you resolve a merge conflict in Git?

Think of a merge conflict like two people editing the same paragraph of a document simultaneously. Alice changes the sentence to say 'The server runs on port 8080' while Bob changes it to 'The server runs on port 3000.' Git doesn't know which port is correct, so it presents both versions and asks you to decide. The key is that conflicts are normal, not errors. They simply mean Git needs human judgment.

A merge conflict happens when Git cannot automatically reconcile changes from two different branches that modify the same lines in the same file, or when one branch deletes a file that another branch modifies. When you run git merge and a conflict occurs, Git pauses the merge and marks the conflicting files with special conflict markers. The <<<<<<< HEAD section shows your current branch's version, the ======= divider separates the two versions, and the >>>>>>> feature-branch section shows the incoming branch's version. Your job is to edit the file to create the correct final version, which might be one version, the other, or a combination.

Internally, Git uses a three-way merge algorithm. It finds the common ancestor commit (the merge base) of the two branches and compares each branch's version against this base. If both branches changed the same hunk of a file differently relative to the base, that's a conflict. If only one branch changed a particular section, Git automatically accepts that change. The three-way approach is far more intelligent than a simple two-way diff because it can distinguish between 'Branch A added this line' and 'Branch B deleted this line' versus both branches adding different content at the same location.

In production environments, large merge conflicts are often a sign of process problems: branches living too long, insufficient communication between developers, or lack of clear code ownership. Teams at scale reduce conflicts by keeping feature branches short-lived (1-3 days), frequently rebasing on main, splitting large changes into smaller PRs, and using CODEOWNERS files to prevent multiple teams from modifying the same files simultaneously. Tools like VS Code, IntelliJ, and dedicated merge tools (KDiff3, Meld, Beyond Compare) provide visual three-pane interfaces that make conflict resolution faster and less error-prone.

A critical gotcha: never blindly accept one side of a conflict. The correct resolution often requires understanding both changes and combining them logically. Another mistake is committing files that still contain conflict markers (<<<<<<). Set up a pre-commit hook to scan for these markers. Also, if a merge gets too messy, you can always abort with git merge --abort to return to the pre-merge state and discuss with your team before retrying.