Another thing I've learned over time is "don't be afraid to introduce commits before your current working state". Let's say you're writing code and you need to

Another thing I've learned over time is "don't be afraid to introduce commits before your current working state". Let's say you're writing code and you need to use component X, and as you dig into it, you realize it's not factored the way you want. Rather than lumping a refactor of component X into one code review with all the rest, it's often better to save your work (using stash or commit), move your git HEAD before your latest work (using interactive rebase), do the refactor that you want, and then apply your other work on top of that refactor. If you're doing more work with component X and realize the refactor needs a tweak, or if you notice a bug from the refactor, you can go back and fix that commit using interactive rebase. When you're happy with the refactor, you send it out as its own code review with a commit message mentioning "This is preparatory refactoring for feature Y". Then both the refactor commit and the feature commit are self-contained and easy for you to look over and easier for code reviewers to understand.