I tend to do a lot of commits. I try to keep each commit focused on a single task. So, for instance, if I need to add error handling to something and improve the output formatting, that's two commits. I would work on one, commit it when it is working, and then work on the next thing. I feel like a commit should be a single, descriptive line and should describe a single code addition or modification. Just my personal approach.
I do exactly this with an extra constraint which is that I try to leave tests green. It is not always possible, but when it is I feel it helps a lot with code review and with auto-review too.
I tend to do a lot of commits. I try to keep each commit focused on a single task. So, for instance, if I need to add error handling to something and improve the output formatting, that's two commits. I would work on one, commit it when it is working, and then work on the next thing. I feel like a commit should be a single, descriptive line and should describe a single code addition or modification. Just my personal approach.
I bet this works nicely too if you need to roll back to when things were working right if you start to see errors happening.
I do exactly this with an extra constraint which is that I try to leave tests green. It is not always possible, but when it is I feel it helps a lot with code review and with auto-review too.
Oh, and then I sqash it all together just before I merge my topic branch because I commit A LOT.