They’re not really in conflict at all. The workflow I’ve been using for ~11 years is:
- Make a branch for my work.
- Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was.
- Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.
- When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was.
- Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy.
This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later.
I’m fact I’ve found that far more useful than a well curated history.
Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.
I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit.
You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.
- Make a branch for my work.
- Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was.
- Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.
- When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was.
- Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy.
This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.