[alisonatwork]

I do this too, but when I come back from lunch I git reset HEAD~1 and keep going till I have a meaningful piece of work to commit on its own. You can also use interactive rebase to reorder or squash commits if you realize that for readability reasons it makes more sense for a refactoring you started later to appear earlier in the stack or for a subpar commit and its subsequent fixup to be combined. This makes the final history more easy to read for reviewers, and (after it's merged) more easy to read for future you and other devs on the project too.

[freedomben]

interactive rebase is (IMHO) the golden ticket for this. Unfortunately, if you're using git as a backup then that means you pushed the commits, so a `git push -f` will be required. I do that all the time and think in general we are unnecessarily scared of it. As long as you're the only person working on the branch, a push -f is NBD. Never do it to master though or a shared branch unless you plan to bring donuts or something in later as an apology.

[ycombobreaker]

Yeah where I work, we strongly encourage interactive rebase on solo feature branches.

In fact, even the hairiest long-lived branches can get cherry-picked apart into several "layers" of branches to get reviewed and merged piecemeal. It's really easy if you're starting from too many commits. It gets harder (not impossible) if individual commits commingle said layers.