tl;dr - At the risk of continuing a flamewar, I’m going to suggest you never use merge commits.
Yup, end of the year is flamewar time.
The context of this particular (possibly unreasonable) suggestion comes with some context. I assume you do one of the folllowing in your hacking:
- Make branches (i.e. a fully private repo/one you have maintainer/committer access to)
- Fork repositories and make pull requests back to a main repo
Merge strategies
In general I consider the contrast here between two merge strategies
- Merge commits represent creating a new synthetic commit that represent where two changes were merged together. Merge commit shave two predecessor commits.
- Fast-forward only (i.e. no merge commits) represents only ever adding commits to an existing branch (no added synthetic commits, just the ones you wrote)
Squashing is actually not quite the same – you can do either of these with or without squashing commits first.
Benefits of FF-only
At the very least here are the benefits of being fast-forward-only
- More Linear history
- Rewritin history is easier
- Easy to stack commits in PRs (assuming you do the work to keep the lower commits updated if/when they change!)
git diff
s remains unbroken
Did I miss anything? Send me an email and I’ll update this list.
Drawbacks of FF-only
Here are some drawbacks:
- Requires a higher level of
git
knowledge
- More complexity
- Bikeshedding over one commit vs many commits in a single PR
Did I miss anything? Send me an email and I’ll update this list.
What do I do on projects?
Here’s what I do on project (GitHub, GitLab):
- Disable merge commits
- Disable squashing
- (optional) Enforce the use of Conventional Commits with CI
- (optional) Enforce a commit limit for PRs (1 per PR) with CI
- Some distinct features are bigger than one commit (or are they)… so this can vary
- Run full test suites on branch/fork PRs
I think the world would be much simpler if people just did this. Merge commits are entirely unnecessary complexity,
and I can’t find a good reason for them.