This may be unclear. If there is code that is comfortably _sitting in production_, refactoring _that_ should be its own commit or PR. If you're designing new c

This may be unclear. If there is code that is comfortably _sitting in production_, refactoring _that_ should be its own commit or PR. If you're designing new code and you write something, tear it down and bring it back up, but it's never touched the main branch, it doesn't matter how much you do to it. In my standard development flow, I commit often, but don't PR, and then at the end, I rebase my whole branch on top of main and shrink it down to one-to-few commits, usually one. Since people are only looking at the commit set at the end of my work in the pull request, that's the only thing that needs to follow the 'refactor vs new code' separation.