Merge conflict (Git)
A merge conflict happens when Git cannot combine two branches automatically because both changed the same part of a file, or one branch removed a file that the other edited. Git stops, marks the competing versions in the file and asks a person to choose the final content. It is a normal part of teamwork on code, not an error and not a sign that something is broken.
Why it matters for a PM
PMs who contribute to a repository, edit copy or docs, or supervise an AI coding agent will run into conflicts. Understanding them removes the fear of touching code, and helps a PM organize work so that conflicts stay small: short-lived branches, small pull requests and regular updates from the main branch.
Example
A PM fixes a typo in a button label on their branch while a developer renames the same button on theirs. When the PM updates their branch, Git reports a conflict on that line. They keep the developer's new wording, apply the typo fix to it, commit and push.
Key points
- Conflict markers show the current version and the incoming one; the resolution is whatever content you keep.
- Resolving means choosing, combining or rewriting, then committing the result.
- Integrating the main branch often keeps conflicts rare and small.
- Run the tests after resolving: a clean merge can still break behavior.
Common mistakes
- Keeping one side for a whole file without reading the other side's changes.
- Committing a file that still contains conflict markers.
- Force pushing to make the problem disappear, which overwrites a teammate's work.
Go further with Module
The courses and lessons that cover this concept: