I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your

I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done. 2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests. 3. Open your code for review, either via a PR or by submitting the patchset to a mailing list. 4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch. 5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch. 6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`. Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch. This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges. Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.