Some battles you choose. The merge conflict chooses you, usually at about five o'clock, usually on the branch you promised would be "ready in ten minutes".

Here's how it goes, in five acts. You've probably performed in this play yourself.

Act 1: Confidence

The feature is done. Tests pass locally. You've been on this branch for, let's say, a while. Two weeks. Maybe three. Time is a social construct.

You type git pull --rebase origin main with the calm of someone who has never been hurt before.

Act 2: The wall of angle brackets

CONFLICT (content): Merge conflict in app/Services/RentService.php
CONFLICT (content): Merge conflict in routes/api.php
CONFLICT (content): Merge conflict in composer.lock
error: could not apply 3f2c1ab... Add rent reminders

❌ The file you barely touched has conflicts.

❌ composer.lock has conflicts, which is like being asked to merge two phone books by hand.

❌ routes/api.php has conflicts because two people added a route on the same line at the end of the file.

Act 3: The investigation

You open RentService.php. Between <<<<<<< and >>>>>>> lies a mystery. Your version calls calculateDue(). Their version calls calculateAmountDue(). Someone renamed the method. In fact, someone renamed half the class and reformatted the rest.

❌ You run git blame to find the culprit. It's a formatting commit. The author is you, from a different branch, last month.

Act 4: The bargaining

You try git checkout --ours. Then you remember you're in the middle of a rebase, where "ours" and "theirs" swap meanings. (During a rebase, --ours is the branch you're rebasing onto and --theirs is your own commits. Nobody has ever remembered this on the first try.)

❌ You consider git rebase --abort, deleting the folder, cloning again and pretending none of this happened.

Act 5: Resolution

An hour later, everything compiles. You run the tests. Something unrelated fails, because the conflict was resolved "correctly" in both files but the logic between them no longer agrees. Git can only see lines. It has no idea what your code means.

You fix it, push, and write "resolve conflicts" as the commit message, which is the developer equivalent of a long sigh.

What actually makes merge conflicts boring

Conflicts aren't a Git problem. They're a time and communication problem. The longer two people change the same code without seeing each other's work, the bigger the bill when they finally meet.

✅ Small pull requests. A branch that lives for a day collides with far less than a branch that lives for three weeks. If a feature is big, ship it in slices, behind a feature flag if needed.

✅ Sync with main often. Run git fetch and rebase or merge main into your branch every day, not just at the end. Ten small conflicts spread over a week are easy. One giant conflict on Friday is not.

✅ Talk before you touch shared code. "I'm renaming methods in RentService this afternoon" in the team chat costs five seconds and saves someone an hour.

✅ Keep formatting out of feature work. Run your formatter (Pint, Prettier) across the codebase once, in its own PR, and enforce it in CI. Then style changes never sneak into real diffs.

✅ Show the original, not just two versions. git config --global merge.conflictStyle zdiff3 adds the common ancestor to each conflict, so you can see what both sides changed from. It makes conflicts far easier to read.

✅ Let Git remember your fixes. git config --global rerere.enabled true records how you resolved a conflict and reapplies it if the same conflict shows up again, which happens a lot during long rebases.

✅ Don't hand-merge lock files. Take main's composer.lock or package-lock.json, then re-run the composer require or npm install for the package you added. Let the tool rebuild it.

✅ Run the tests after resolving. A clean merge isn't the same as working code.

Merge conflicts will never disappear completely, and that's fine. The goal is to make them small enough that resolving one is a two-minute task, not a story you tell other developers.

What's the worst file you've ever had to resolve a conflict in? I'll nominate any lock file, ever.