Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
If you dig functional programming then I like to commit every time I start working with a new function. It's basically a good move if you want clean code
As much as you can easily describe in a commit message.
karma105203yDepends if its rework lol 😂
Recently I ported a framework from Java to c++. Let's just say I did it all in one commit... no point in struggling to fix errors when half of them are related to the rest of the code not being done. Otherwise, I make a commit either small fixes and polishing or a feature, but never mix. Also don't commit broken code until you fix it.
chadd1751443yCommit code that is related to itself. Kind of like how a good paragraph reflects a central point.
Commit before you refactor.
Commit after testing the refactor.
You don't have to commit working code if you just need to bookmark your work, but I personally like to get it functional at least before pushing.
Don't punch in your commits on a timer. Punch in your commits when you've accomplished something. Doesn't have to be a big accomplishment, doesn't have to be small either.
bioDan54173yDepends on the commit for me.
initial commits are usually huge and bulky, like the first git push of a repository for a service/monolithic component. Then i categories my branches according to 'git flow' for new features/bugs/hotfixes so eventually each commit is related to its own bug/feature branch.
I try not to do more than 5 different files per commit, but like @waqas-ibrahim said, its really about the description of the change you did in the commit message.