Well committing in here refers to staging up the changes that you make in your local machine and far from this pushing it to the branch where other teammates can get themselves update with what you’ve done in project.
No, talking about myself I generally work on different projects almost daily. And which lead to change in programming environment.
By this I mean like if you’re working on some project and commits some changes with some message that might not be very descriptive and you switch to some other work.
When you return back to the older project to work on it again, you might need to get familiar with what you did last time and what changes have already been made by your teammates(if you have any :P) before you actually start to work.
This leads to confusion and reduced in degree of DRY rule.
Commenting as you work
When you’re doing some work on a project make sure you place comments on what these lines of code do. This slowly but surely increases the productivity of you and your team when they return to work, as it reminds the programmer about things rather than understanding them him/herself.
Writing less but more
Writing a message during your commit gives idea about what this commit does and contributes to. So, giving a write message counts +1 towards productivity.
Don’t commit after every changes
It’s recommended that you commit once you’re sure you’d commit your work. Completing a section of work and doing commits in order always benefits.
Don’t write weird and non-sense messages
Committing a small yet informative message is necessary. It doesn’t have to be a whole novel.
git commit -m "today i changed some theme colors and added few of mine because your colors suck I fkin hated them so i got rid of them. Apart from this I also added a Palette section it's was a hell lot of work i better get a raise :P"
git commit -m "added Palette section & few theme changes"
Hope you find this informative.