How often to commit


… in the context of coding that is.

I’m intrigued to know how often developers reading this commit code and why? Frequent commits are trendy these days, the “hip” developers are all doing it (I don’t know if I qualify as “hip” but I’ll pretend I do). Especially with the advent (or at least wide-spread adoption) of distributing revision control systems like Git, frequent commits seem like a great idea. All of the backing up of code and high level of granularity in changes without the pain of constant difficult merges.

I work with a lot of older developers who have been coding since before I was born. These developers (who have a lot of experience and knowledge) always seem very reluctant to make frequent commits and also seem annoyed that they’re expected to comment their commits. To me, it’s very natural and I find it confusing and bewildering working even a relatively small project without any commits that are at least tied to requirements or specific major features of the application.

Any war stories with regards to version control systems, older developers, and general crankiness with the combination of these two?

A good StackOverflow post here has some good thoughts.

(The screenshot is on revision 40. Or commit de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3 if you’re using Git. When I said frequent, I meant it! :-P)

  1. No comments yet.
(will not be published)