Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
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
-
chadd1746437yCommit 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. -
bioDan61597yDepends 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.
Related Rants
How much work should a git commit include?
undefined
git
github
commit