I had two agents building two games for the arcade at the same time. One was working on Word Runner on a branch called e6-11. The other was working on AI Typing Star on e6-12. A branch is just a separate copy of the code where work can happen without stepping on anyone else. Each agent finished its game, and each one did the responsible thing and wrote down how to deploy it.
They both wrote those notes in the same file, DEPLOY.md, and they both put them at the bottom.
When it came time to bring the two branches back together, git stopped and reported a conflict. That's git telling you two changes touched the same lines and it can't decide which one wins. It marks the spot and leaves the decision to you.
A conflict that wasn't a disagreement
The word "conflict" sounds like an argument, and usually you treat it like one. Somebody changed a timeout to 30, somebody else changed it to 60, and you have to pick. One of them is right and one of them has to go.
This wasn't that. The Word Runner section said how to deploy Word Runner. The AI Typing Star section said how to deploy AI Typing Star. Neither one edited the other. They didn't even share a sentence. The only thing they had in common was where they landed: the same spot at the end of the same file. Git doesn't read what you wrote. It sees two edits on the same lines and stops.
So the fix was easy, and it's right there in the merge commit, 21c1f60: "keep both game sections." I took both of them. I didn't choose a winner or blend them into one section. I put one after the other.
That's the first thing I want you to take from this. When two parallel pieces of work each add their own thing to a shared file, the resolution is the union, meaning you keep everything from both sides. If you find yourself picking between two sections that describe different things, stop. You're about to delete somebody's work because of where it was placed.
The second time is the real signal
Here's what bothered me after I'd fixed it. The fix was mechanical. Any time two game branches finish around the same time, I'll get the same conflict in the same file and resolve it the same way. Keep both. Keep both again. That isn't judgment. It's a chore the file keeps handing me.
And with agents running in parallel, it's going to happen a lot. The whole point of running several sessions side by side is that they finish at overlapping times. A single shared list of deploy notes is basically a spot where they're set up to collide.
The conflict was never about the content. It was about the layout. Every new game has to append to the same place, so every pair of new games fights over the last few lines. If a collision is caused by structure, you fix the structure.
The fix is to give each game its own file. Something like deploy/word-runner.md and deploy/ai-typing-star.md, with no shared bottom to fight over. Two agents adding two games would touch two different files, and git wouldn't have anything to stop on. If you still want one page that lists everything, generate it from the folder, or keep a short index that links out. The index rarely changes, so it rarely collides.
I don't think you should split every shared doc the first time it conflicts. One collision is just a collision. Keep both and move on. But when you notice you're resolving the same kind of conflict a second or third time, and every time the answer is "keep both," the file is telling you it holds a list of separate things pretending to be one thing.
The one-liner I'd give a friend: if the answer to a merge conflict is always "keep both," stop merging and split the file.
Seth Shoultes builds at garagedoorscience.com and writes here when the building produces something worth saying.