git / other VCS - how often to commit? [duplicate]

Question

I've been a programmer now for over 11 years, and am just starting to get into version control for real. The places I've worked at have never really used version control (one committed at the end of each day, the others simply haven't bothered).

I am not happy with the way that I've been taught to version control (programme.js, programme.js.bak, programme.js.bak.20110901 etc) and so have been teaching myself to use git.

I currently use it along with github to keep my .vimrc file current across 4 machines, but I'm never sure when I should consider a change a commit, and when it's just a change which should be included along with another commit. I have started to use it for javascript development too and find it awesomely useful :)

My question is: At what point do changes become a commit? As I said, the only company I've worked for who used version control did it at the end of the day - this doesn't seem sensible to me. I feel that they should be more atomic. But my question is how atomic?

Is a bug fix for a function enough for a commit? Should I fix three (unrelated) functions and commit them all at once? Should I commit after changing the condition in an if statement?

On personal projects, I commit after any change. I personally find that useful, but I don't know if it's bad practice or annoying.

How do you do it, how does the industry do it, and what are best practices?

(I'm a web developer so work on short projects - perhaps a month long)

Answer 1

Each individual change should be one commit. A few things to consider:

• Having stuff committed means that you can roll back. Assume you have a bigger task to be done. You're 50% done, that part looks good so far. Then you continue and break something massively by some mistake. Having the commit in between means you can go back there and didn't loose all of the work.
• Version control is not a place to dump data and forget. Version control provides a history. Lateron you can use the history, including my favorite annotate feature, to figure out why a change was made (and who is responsible) this often helps. But to work properly the change should be small and self contained.
• When working in teams it's great to have people reviewing it (actually even when working alone this would be great ;-) ), for a review it's good to have small parts which can be reviewed without being mixed in between unrelated changes.

Looking at git specifically, it allows local commits which are not visible to other people, so you can even commit broken code locally and fix it with a later commit before pushing. git commit is very fast so committing locally doesn't really interrupt the development process. Git also allows rewriting commits, so many commits can be rewritten into one before being pushed, which makes it easier to review - while rewrites are dangerous and should be done with care (don't rewrite after push etc.)

Answer 2

When it comes to git, I believe one should commit as often as possible - some people commit every successful compilation. Don't confuse commits with pushes - a local commit does not have to be pushed (and with git, you should use many branches as they are cheap).

This should be the rule all around, but some SCMs are too slow for such a rule.

Personally, when using SVN, I try to commit several times a day and only when I am certain the code is in good condition (ie compiling and passing all its tests).

Answer 3

You commit when you can write a commit message (you write those right... :) that clearly describes the single new feature/function/bugfix/improvement included in the commit.

Answer 4

If you are fixing independent bugs, they should be seperate commits. The reason being, if you later find a problem with you fix for bug A, and want to reverse it, it is much easier if it is not combined with bugs B and C. Especially if there have been additional code committed before you found the problem. The same logic applies to features as well. Basically, the smallest unit of working code that someone else can checkout and use. Even if that someone is you on another machine.

Answer 5

Small commits aren't exactly that bad when they are clearly about fixing specific things. It's understandable that revision history can get crowded but it can also provide interesting insights about development style of the project team. When new developer joins the project, it can be useful for him/her to read revision history list if the changes are described clearly enough.

Still, there are some guidelines that vary project by project. Some have set of tests that must be run successfully before code can be committed, others are configured to run tests automatically after committing (useful example of public Continuous Integration test service is Travis CI).

Answer will also vary by the type of version management system used in the project. Having mostly used DVCS type tools, I feel that it can be useful reminder for myself to make small commits as it also works as partial documentation. Too large amount of smaller commits can be confusing at first but according to research, most of the commits in Open Source projects are small. There might be variance in how internal development works but often it's the little things that start to annoy in tools and small changes often are enough to fix specific problems.

Some of possible reasons for keeping it small:

"You should try to split your changes into small logical steps, and commit each of them. They should be consistent, working independently of any later commits, pass the test suite, etc."

Have found useful alias for seeing list of git commits in console. lg has really helped to see changes faster and more clearly than various other commit list views:

# Show history in short format with colors
alias lg="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"

Answer 6

I always strive for having my commit log looking like the changelog for my program. That's not an achievable goal, but something to strive for. It pretty much defines that I want a separate commit for each new feature and each bugfix, but not too many.

Additionally when working in a team, I think of a commit as a letter to a fellow developer, describing the change I have made. I don't want to spam my fellow with every little commit I make when developing a new feature. It will leave a lot better impression if I just produce one larger commit, as if I had written the feature flawlessly on my first attempt.

But on the other hand I don't want to fall into lonely darkness... spending a month crafting one huge perfect commit. I want to keep my fellow developers aware of my progress. Any big feature can usually be split into meaningful pieces. So as a rule of thumb, one public commit per day should be the minimum.