One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.
This is the approach I try to take. It requires discipline but it has helped on several occasions.
The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.
Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.
The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.
Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.