Table of Contents
Atomic git working commits are impractical
From a popular HN thread titled Git is my buddy: Effective Git as a solo developer (mikkel.ca):
twodave 22 hours ago [–]
The "every commit must be independent" ideology sounds nice when you write it down, but often you'll have such large changes that in order to make them independent you'd have to basically finish an entire feature. In those cases I tend to just indicate WIP (work in progress) in my commit messages with a brief snippet about what progress was made.
This way, if you skip all the WIP commits you'll have mostly runnable code, and if you want to review a PR commit-by-commit it's easier to see what was being attempted in each commit than to only look at the feature as a whole.
Once is dunce, twice is nice, never thrice
This seems like a classic case wherein messy execution should be followed immediately by meticulous cleanup.
Messy execution exploits top-of-mind opportunities without permitting administrative overhead chores to distract.
Immediate meticulous cleanup constructs an idealized legible history, with the advantage of familiar recency.
The human brain itself works this way, consolidating long-term memory overnight during sleep.
The next question is how best to implement this workflow in git.
One option would be to use complex arcane git commands to transform a messy actual work history into an idealized legible official record. Even if the user performs this transformation perfectly, at minimum it causes a loss of information about the actual work history, by altering messy commits.
Therefore it's better to write completely new commits for the official record. One's idiosyncratic work history doesn't belong in the public collaboration git repo.
I find it easier to use separate git repos, one personal and the other collaborative. I transfer info between them only via manually syncing the working trees.
It may take syncing from multiple personal commits to update the official record sensibly, which sounds like a burden, until compared to the alternative of trying to understand a mysterious ancient official commit embracing multiple unrelated changes.
Code spelunkers unsatisfied with the terseness of the official record should be free to investigate the contributing dev's personal repo to sort through his chaos for clues.
Lazy solo devs of juvenile projects may resort to an official record that is little more than a series of (hopefully) working checkpoints. The lean startup sometimes skips showers as well as meals.