[mdehaan]

Maybe it's just me, but using short lived topic/feature branches and squash merges seems much easier than remembering all of these steps to "fix up" all these things.

I think it becomes some what of a game to use all the more obscure corners of git when a good 20-30% of it goes a long way.

Using less commands is more.

[mcknz]

I agree, but that also requires a discipline/foresight not all of us have. :) I try to keep my feature branches as atomic as possible, but sometimes I get ahead of myself and work on multiple things that really shouldn't be in the same commit. I wouldn't use this model as my main workflow, but it's definitely useful in certain scenarios.

[gcb]

if your code is 'live' and you plan ahead a few features: feature branches.

if you are running as fast as you can for the first releases, what i do is use feature prefixes on the commits. And of course, a commit can have several prefixes.

of course, if i have to cherry pick something, i still have to look at each commit, but with prefixes it's easy. And i have the time i didn't spend thinking ahead for something i don't even know i will need.