I've seen a lot of people take the approach where they commit all the time with little things like "fix typo" or whatever, then clean it all up before sending t

I've seen a lot of people take the approach where they commit all the time with little things like "fix typo" or whatever, then clean it all up before sending to code review. One downside to that approach, though, it that it can make it harder to organize your work into small coherent chunks, each of which is a self-contained step that can be its own code review. My preference is to instead have one commit per code review, and use "git commit --amend" to make changes to those commits. If you're worried about losing work with the "git commit --amend" approach, some things to keep in mind: * Git keeps your history even when you use "git commit --amend"; it's in the reflog. So you can do "git reset HEAD@{1}" to undo an amend operation, etc. * All JetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc) have a "local history" feature that automatically keeps track of every change you've made to your code, independent of what git commits you made. I've found it useful several times, especially when I mess some git command up. If you're not using a JetBrains IDE, I'm sure there are other similar tools.