It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite.

Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful.

If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.

While some might be more rigorous about working on a commit at a time, a couple other helpful bits are:

- Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc.

This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things.

My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.