I commit as soon as a single functionality makes sense as its own. Simple example: If function X uses function A, B and C. I'll commit after finishing A, B, or

I commit as soon as a single functionality makes sense as its own. Simple example: If function X uses function A, B and C. I'll commit after finishing A, B, or C. And once X is then, I create a separate commit. I also ensure the code still runs most of the time. How I group them depends on how complicated it is. The more complex, the more commits. This helps me write code that are more standalone (easier to replace & test). Also helps to clear the cognitive burden when developing larger features. Anything that's committed are pretty much "done". So if I leave any work mid-way, I can simply look at the untracked files to know where I was at. Then at the end of the work/PR, I go through every changes to make sure everything makes sense. In practice, this means that the first code I write is often the last I commit (see my simple example above).