[toddsiegel]

Generally, I like the middle ground of reasonably small branch sizes and small, well-organized, well-written commits.

Walking through a half dozen or so commits in a PR is still manageable.

Too many small things deployed over time can be a pain to roll back too.

On the flip side, huge change-the-world deploys are bad too.

It's a balancing act of managing the initial feature size, getting it out, layering on more in subsequent releases.

Where tiny deploys work really well is when deploying refactorings, little housekeeping chores like upgrading libs. If, while working on a feature or bug, I need to add a missing test, refactor, or upgrade a lib, I extract those commits out and deploy them ahead of time when possible. That way the resulting feature branch is very focused on the feature at hand.

[FLGMwt]

I think I still prefer the logical diffs to be at a PR level. I know at least personally that I commit a lot of experimental code that I back out of for the eventual implementation.

Doing git fu to reverse that is not worth the time imho. I'd rather invest time in factoring (and testing) tiny deliverables.

At least then, you still have the diff as a travelogue.