Git stops and asks for a decision. It’s not drama, and it doesn’t mean the code is broken or someone messed up. It means two lines of work collided in a place where an automatic merge would be risky, and the system refuses to guess.
Think about two people editing separate copies of the same client proposal. One rewrites the pricing paragraph; the other rewrites that same paragraph differently. When you bring the drafts back together, you can’t keep both versions in the same spot without deciding what it should say. That’s a merge conflict.
How it shows up
This comes up with branches, where a person or agent works in a safe lane while someone else works in another. When both lanes come back together through a pull request, Git compares the changes: different files or different parts of a file usually combine cleanly, the same part gives you a conflict. You may see conflict markers showing each version and where Git got stuck, and a person or agent edits it into the final version, saved in a commit. AI tools can help, but they aren’t mind readers: an agent can propose a clean file, but you review the decision, because the right answer may depend on business context, not syntax.
Why you care
The client-facing point is shared skill safety. If someone changes a shared skill and there’s a conflict, you want to catch it before the change ships to everyone. The conflict is the warning light: two people edited the same thing, decide before this becomes official. Conflicts are a coordination signal, far cheaper than silently overwriting someone else’s work.