In principle, I agree with the author. Although I don't think git needs group commits to achieve this functionality. My preferred workflow for the past couple o

In principle, I agree with the author. Although I don't think git needs group commits to achieve this functionality. My preferred workflow for the past couple of years has been to interactively rebase and squash/fixup! the commits so that each commit represents a functioning state of the code, which more or less achieves the same thing as what the author wants. However, this approach only works if all the developers on a project buy in to this philosophy. As much as I dislike squash and merge, it's better than the alternative of trawling through a git history with dozens of "WIP" and "Fix tests" commits and janky rebases/merges.