I believe in a One Change At A Time policy: I'd like to be able to, at least in theory, measure the effects of any change. If you slap two changes together, tha

I believe in a One Change At A Time policy: I'd like to be able to, at least in theory, measure the effects of any change. If you slap two changes together, that becomes difficult or impossible. One change at a time has the benefit of not polluting traceability of what was done and why, in the ticketing system. If a commit for ticket1234 was to fix a bug in the payment system, and the commit has unrelated code fixing up user data access, that's bad in my opinion. I've found myself in many code bases where the only trail of breadcrumbs I've had is ticket references in the commit messages. When these aren't reliable, you're left with not much at all.