2 ms·

I see the purpose of code versioning in being able to save the code fast, being able to reverse code changes fast and doing code merged with ease. If some phil

I see the purpose of code versioning in being able to save the code fast, being able to reverse code changes fast and doing code merged with ease. If some philosophy stays against someone's productivity I don't believe it is a good thing. I would let developers commit in every state they find easy, provided the code builds and the commit comment describes what is being committed. I think it is the PR which we can push more demands on but not commits. I, for example, dislike having to track any small change I have made and commit it. I like committing larger parts which contain a functionality.

imaltont 4y ago
> I, for example, dislike having to track any small change I have made and commit it. I like committing larger parts which contain a functionality. This is pretty much the suggested way by the creator of git too. A commit should contain the necessary changes for one bit of functionality/bug fix. This imo makes the history pretty neat and tidy, while at the same time making it easy to search through with blame/bisect whenever you need to. Giant commits (multiple functionality/whole project/extension squashed into one) makes both of those hard to use and in some cases pretty much useless outside of finding who did it and hope they still work at the company and remember their state of mind when they did the change.