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.

It's very tempting sometimes, and small refactors are fine and normal practice, but if I need a substantial refactor, I tend to do temp commit; refactor; then rebase and reorder commits with git rebase -i. It really doesn't take a lot of time once you do it a few times.

The thing is, once you get a habit of committing often (also unfinished WIP work) in small portions, with minimal effort you can then reorder and squash commits and make the final PR really much easier to review _even for yourself_, and twice as much for everyone else

I’m the same. Refactoring is a way for me to “takes notes” as I learn a codebase.

Version control makes things so easy I typically always commit the refactoring work to mainline first (code review and all) then fix the bug or repeat with another refactor.

It’s also typically faster, because the refactoring alone is a significantly smaller code review than the refactoring+<change>, and I can keep working on the <change> (i.e. bug fix/feature/more refactoring) while that CR gets looked at.