I’d say around 1 time a week. I guess it just tends to happen with a lot of devs working on a single project. But we do have a daily rebase policy for all development branches, so I can’t remember the last time it wasnt some includes mixing badly, or a file being moved. These are all easily fixed.

Fairly often.

I tend to fork open-source stuff when I want to make my own adjustments, often the adjustments I make are not wanted upstream. So I’m doomed to having merge conflicts for all eternity.

Often what happens though is that I fix some bug, and then a few months later the upstream fixes it in some other way - so the conflict resolution is to basically just throw away my own (clearly superior but now obsolete*) changes, to avoid more conflicts later on.

(* I’m joking. But it does feel bad to throw away good work.)

Rarely. Require linear history for the win.

My team practices rebasing instead of merging, but generally our tasks are pretty separate so conflicts are uncommon. The ones that we do have are not that big.

However I am anticipating more of them now that we’re changing build systems

In my team of four developers, very rarely.

I may even be resolving more conflicts against my own changes in other branches or from splitting up changes in a branch than against others’ changes.

When they occur, TortoiseGitMerge usually resolves them automatically.

Honestly, almost never. That’s why there are daily meetings, so that you don’t change the same code at the same time.