It seems to me that the author is conflating two very different activities, akin to how writers must learn to separate the act of writing from the act of editin

It seems to me that the author is conflating two very different activities, akin to how writers must learn to separate the act of writing from the act of editing: Attempting to edit or to polish when writing impedes writing, impedes just letting words flow. Stuck? Add a parenthetical note (TK - need X to happen to Y here - TK) and move on. (Why TK? Because it rarely occurs in English words and so makes a useful, searchable marker for changes or challenges to be added or addressed later.) Coding is akin to writing. Get in and stay in the zone, let it flow. Don't worry about the other things. If you want to commit to support rewind and blame, do so, just don't push (or don't push to the real remote, push to a working remote set up for the purpose, one you reset periodically). Commits are cheap and git provides plenty of tools for massaging them to make sense (and even appear to be in whatever order you think best!) after the fact before pushing them for real. Between patching and cherry-picking and squashing and other capabilities, the tools are there. Committing is like editing. Well, more like publishing. It is the act of recording your work... ...and telling OTHERS what you did. They are different activities. Both can be hard work. Do the context switch and do the second in the way that makes the most sense to your workflow, to the workflow you share with others. It might be tedious and it might be a pain... ...for example, if all changes need a distinct issue, so you have to cherry-pick the typo, create an issue for it, commit the change referencing the issue, etc., etc. I'm glad I don't work there, wherever that there is. I know theres like exist, though. I'm glad the author developed a tool and approach that helped them, but git isn't to blame for the conflation of two remarkably distinct activities.