I don't just worry about merge conflicts. I worry about merges that generate no merge conflicts, but still create bugs because of the way changes on two different branches end up interacting with each other at run time.
In general, I feel a lot more confident with using feature flags and the like to keep work in progress from prematurely going live than I do using branches to do the job.
Or, if I could take a stab at saying it pithily: Having your code be continuously integrated is a prerequisite of doing continuous integration.
No, it's certainly not perfect. But, not being aware of a solution that's perfect, I've had to content myself with something that's merely better than anything else I've tried.
I generally like to have feature flags default to true in tests. It helps avoid this sort of situation, because if they ignore the flag, they’ve probably broken some tests. And if they only put it in the flagged path, their code won’t work in prod, but it probably won’t break anything either.
I think of those as "logical" merge conflicts, as opposed to "literal" merge conflicts, the kind detected by git. Having good integration tests is crucial!
This is definitely my biggest worry, too, especially since we rarely have merge conflicts on our 6 person team.
Merge conflicts are rare for two major reasons:
1. We plan our changes to avoid the likelihood of merge conflicts. Specifically, we try to avoid two people working on similar areas of code at the same time.
2. We have functionality split into a fair number of different repos (though I probably wouldn’t call them microservices), which not only makes 1. easier, but simply reduces the chance of two people pushing commits to the same repo.
Part of 1. also involves giving slightly bigger pieces of work to a single developer, so that person can see it all the way through from the start. That way, there may not be as many short PRs that are quickly merged, but that developer can really wrap their mind around the complexity of the problem and hopefully have a higher quality functioning product at the end.
Of course, we also have our use cases reasonably solidified when we start building, since our company is over 8 years old and we take the time to know our customers’ desires fairly well (and are always learning more, or course!).
This is also a argument (among many) against rebase. There are a lot of automatic merges peppered in the history and you can track down the bug to an automatic merge (using eg git bisect) only if the history is preserved.
I don't see thus as an argument against rebase. In fact, rebasing your branch interactively allows you to examine the conflicts, if any, in the context of the feature branch and fix them. If you merge the base branch into your branch, you get a mix of changes that are hard to reason about in the context of your feature branch and the automatically generated commit message doesn't provide much information about what was done to resolve any conflicts.
On the other hand, its a lot easier to see if a conflict resolution attempt didn't work during a rebase because the individual commit diffs and the overall diff would make obvious (e.g., unrelated code in the master branch was changed out removed).
In general, I feel a lot more confident with using feature flags and the like to keep work in progress from prematurely going live than I do using branches to do the job.
Or, if I could take a stab at saying it pithily: Having your code be continuously integrated is a prerequisite of doing continuous integration.