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
-
Voxera113888yDepends on situation.
In a large project many very small commit can lead to a very verbose commit history but if you use the squash feature to join all the small commit into reasonable units, something who's changes can be described in one or a few lines I see no real problem.
But looking through history an finding that more than half the commits is essentially empty is a bit tedious. -
If it makes sense to you. It isn't really a problem unless your metrics people take number of commits to measure productivity.
-
tkglaser1628yI always commit a logical unit. So when it turns out "x isn't working" I can just roll back commit "x".
-
anekix3918ySo you have been using git in a wrong way! It's not about commiting any change you make but it's meant to commit when you have a minimum working setup that you would like to revert back In future if things mess up and still have a working codebase. Suppose I have a codebase and I add 2 more lines and commit them. But those 2 lines alone were not standalone but were meant to be a part of some bigger code block now what's the use of reverting back if you can't get back to a working code? Have you heard things like some app or software product introduced a new feature which broke the existing app(it's quite common) so what they do is they revert back to older codebase without thinking a bit but still have there app running smooth as it was before
I always commit even if i just add a new line in html.
I can do 10-15 commits a day. Is it bad habbits or good habbits?
undefined