A merge conflict is what 📝Git reports when two branches change the same lines of the same file in incompatible ways, so it can't automatically decide which version to keep and stops mid-merge for a human — or agent — to resolve by hand.
Git merges by comparing two branches against their common ancestor and applying each branch's changes automatically wherever they don't overlap. When both branches touch the same lines, Git has no way to know which change should win, so it pauses the merge and inserts conflict markers (<<<<<<<, =======, >>>>>>>) around the disputed section, leaving the rest of the file merged normally. Resolving one means editing the file down to the intended final content, removing the markers, staging the file, and completing the merge or commit.
A merge conflict is narrower than it's sometimes described as: two agents or people finishing work around the same time doesn't guarantee a conflict — if their changes don't overlap textually, Git merges them automatically with no markers at all. What rises with concurrent work isn't conflict probability per edit, it's the raw number of concurrent edits, which raises the odds that some pair lands on the same lines. Merging the target branch back into a feature branch frequently, before opening a 📝pull request, surfaces conflicts earlier and in smaller, easier-to-resolve batches.