The rule we use is: DAGgy fixes for preference, then create multiple fix/feature branches and use rebases to eliminate conflicts. The idea is that each individu

The rule we use is: DAGgy fixes for preference, then create multiple fix/feature branches and use rebases to eliminate conflicts. The idea is that each individual branch is based on a commit chosen such that it won't conflict when merged. This is generally rather easy to do, and for feature work it's compatible with a 'simple' rebase workflow: simply rebase onto master whenever conflicts start to show up. For bugfixes it's rather useful to be able to base a fix on the commit which caused the bug (or a common ancestor of all maintained releases which have it) and just submit multiple merges. Conflicts are a fact of life: you either deal with them as part of a rebase, or you deal with them when merging. But the testers or reviewers are accepting to merge, and they might not be the right people to resolve the conflicts (plus GitHub's PR workflow provides no nice way to deal with merge conflicts), so the author should fix it. tl;dr: Non-FF non-conflicting merges only, so your changes get integrated as a 'single' commit in first-parent history, but you get to pick where you base the branch. Props for minimising 'copy' branches. Does depend on density and structure of code, of course. If every feature branch is touching the same file, you're going to have problems either way.