Rarely. Require linear history for the win.

Depended on the size of the team in my experience. With a project of ~50 devs split into 10 teams, I was having to resolve conflicts perhaps every other PR. But training and standards for workflow can certainly help.

We’re a small team, so generally are able to divide up work so that we’re not treading on each others toes. If it does happen it’s usually because we’ve made some project wide change like retrofitting auditing or something.

I’ve not heard of fugitive, I’ll have to check it out!

Occasionally I’ll get hit with a few unwieldy conflicts. Usually it’s one or two lines, and always a whitespace issue because someone’s code style just has to be different.

I work on a big open source project with hundreds of committers, so quite often — I’d say a few times a week, maybe a third of my PRs.

Quite often, mostly because the project is rather huddled and some devs refuse to use proper tools and often cause unwanted whitespace changes.

Yes, we did talk about it, but if the principal architect thinks that autoformat is at least as evil as proper documentation, it just won’t happen for him.

I’m a hobby dev (for now), and work almost exclusively by myself so very rarely.

It generally happens often without pre-planning and modularizing sections of developed code (even harder with data science, given the often functional nature of data science code bases). But when it does happen, it doesn’t have to be aweful.

To resolve, I generally just create a safe local branch to temporarily complete the merge in that I created form my local copy, and then I pull in the remote copy that I want to merge in with mine using git merge -X theirs ${THEIR_BRANCH_NAME}, which favors their remote changes over yours (I assume origin is more correct than me). Then, conflicts will arise, and you manually perform diffs and checkin the final version with conflicts resolved as a new commit locally. Once complete, it is generally safe to push that temp branch to the remote or your fork for a Pull Request submission, or you may merge the temp branch with the conflict resolves into your running branch. Either way, before the PR, make sure to run tests with the integrated changes first, and to pull merged remote afterwards to fast forward your running copy (such as with git merge -X theirs origin/${HEAD} or git pull origin/${HEAD}

Best answer though: pre plan your code base to include some modularity so that 2 people aren’t actively working on the same file at once, encourage daily check-ins to remotes and daily pulls, and ensure that headless unit tests are in place for critical areas, such as logic and boundary cases, at minimum (and that those run in CI/CD). +1 if you use uniform docker tooling to ensure all environments, even local, are the same. And another +1 if you have good telemetry based on APM metrics and traces for after code is integrated.

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.)

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.

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.

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

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

I have to resolve them way more than I should. We have internal devs and external devs and there is a lot of treading on toes. For any conflict that isn’t super obvious (90% are) ^* I just ask the two devs involved to resolve it together, in a sensible way that keeps the unit tests working.

^* Usually the non-obviously conflicts are the ones where it’s not just a matter of choosing A or B, but splicing A code with B code.

At work, very rarely so far. I think I’ve run into my first merge conflict in six or seven years last week.

At home, quite often with Part-DB-symfony, largely because of the composer.lock file.