Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I am a recent (as of yesterday) college grad - BS in Computer Science. I've been a huge fan of version control ever since I got mad at an assignment I was working on and just started from scratch, wiping out a few hours worth of actually good work. Whoops!

Since then, I've used Bazaar and Git (and SVN when I had to for a Software Engineering class), though mostly Git to do version control on all of my projects. Usually I'm pretty faithful about how often I commit, but on occasion I'll go for a while (several functions, etc.) before writing a new commit.

So my question for you is, how often should you make commits? I'm sure there's no hard and fast rule, but what guideline do you (try to) follow?

share|improve this question

marked as duplicate by MichaelT, Kilian Foth, Thomas Owens Sep 16 '13 at 17:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

add comment

11 Answers 11

up vote 30 down vote accepted

Whenever I have something that works (meaning, doesn't break anything for anyone else) I'll do a check-in. I write most of my stuff test first, so that means every time I have a new test that passes, I check-in.

In practice that means a few times per hour. At least a couple of times every hour, with 5 being quite a bit.

share|improve this answer
3  
I really like this answer - especially since you mention writing test cases. That's something they didn't teach (at all) at my University, which I'm quite sure is a mistake. However, the company that I'm going to work for is just now beginning to migrate in that direction, and from what I understood from the interviews, there's a lot of personal leeway as to using your own SC/Testing. I'm hoping to be an example of how good those processes are! –  Wayne Werner May 9 '11 at 12:14
add comment

You should'nt commit based on a time basis, but on a feature basis. Whenever you add a new feature that's worth commiting, commit. You added a working method? Commit. You fixed a typo? Commit. You fixed a file wrong indentation? Commit. There's nothing wrong commiting small changes, as soon as the commit is relevant.

What is wrong is commiting a huge number of changes, with no relations between each others. It makes it very hard to detect the commit source of a given regression.

Sometimes, I make twenty commits in an hour, and sometimes I commit once a day, depending of the amount of code that was modified.

Making small commits allows you to use very powerful tools like git-bisect.

Don't forget the rule n°1 of the commiter : never break the trunk. If you need to make several commits that are likely to break the trunk, create a branch instead.

share|improve this answer
2  
The 'never break the trunk' rule is a bit softer when you're using a distributed SCM, since you can commit locally without doing any damage; the rule then only applies to pushing, not committing. –  tdammers Aug 2 '11 at 20:29
    
+1 for mentioning "to detect the commit source of a given regression" –  Ida Jun 14 '12 at 2:51
add comment

At least once a day, usually three or four as I tend to commit anytime I take a break. I work on my own, so I don't have to worry about messing someone else up, and I can always revert a file if I think I've gone down the wrong path.

I had a bad experience once when I wasn't making commits regularly and my hard drive crashed and I lost a few hours work. Since my repository is on another machine and is backed up regularly, there's no reason I should have lost anything.

share|improve this answer
add comment

It depends a little on what the development environment is.

If you're the only one contributing to a code base, then a deferred commit won't be that crucial. However, if you're in a team of several developers, and everyone thinking "oh well, I'll wait with the commit a little" then you'll often end up handling a lot of conflicts and losing a lot of time.

The general rule (for both scenarios) would be: Commit as often as possible. If you think "it's not ready yet" (because it'll break the build or simply isn't done yet) then create a branch and commit to that branch but make sure you do commit.

share|improve this answer
1  
+1 for branching - I started doing this on my own projects every time I thought "ooh, let me demolish this feature and replace it with that other one". So far it's worked great. –  Wayne Werner May 9 '11 at 12:15
add comment

On DVCS, I commit basically anytime I'm starting on a change that would be really annoying if I couldn't undo, anytime I need to share with others, or anytime it would be really useful to see what I changed since that point. That ranges from several times an hour to a couple times per day. Also, I very rarely commit when my build doesn't at least compile and run without immediate segfaults, although that can be useful too if you want to be able to isolate and share just the fix for that particular bug.

Note with centralized version control, which you are very likely to be required to use on the job, you generally don't commit until you're pretty sure you won't get a storm of angry emails for doing so. Depending on how independent the changes you're making are, and how much your company subscribes to the continuous integration dogma, that's more along the lines of once a day to maybe once a month on a big new feature.

That frequency difference is one of the main reasons I use git on top of my company's official centralized VCS.

share|improve this answer
2  
"... you generally don't commit until you're pretty sure you won't get a storm of angry emails for doing so." Or you learn to use the branching features of your VCS so you can commit as often as necessary without committing broken code to the integration branch. If your company understands version control at all, then "once a day" will probably get you a warning. "Once a month" will eventually get you fired. –  E.Z. Hart May 9 '11 at 7:31
1  
This really sums up my thoughts. Commit when I want a "checkpoint" that I can get back to if I screw up. Merge only when the feature is complete and the overall software is not broken. –  Tamás Szelei May 9 '11 at 13:42
1  
@E.Z. Hart, it's not a matter of "learning to use branching features." Most companies don't allow the rank and file to create branches on the central repository, at least none I've worked at, because of the clutter hundreds of developers would create on a single centralized resource. Such decisions are made by committee, can take a month just to convince the right people, and feature branches are generally reserved for very large efforts by multiple people. –  Karl Bielefeldt May 9 '11 at 13:45
    
I prefer to check in intermediate stages no less frequently than weekly, but sometimes that just isn't possible if you have to temporarily break a lot of legacy code in order to add a feature. My "once a month" comment was meant as a worst case upper bound, not as a regular practice. –  Karl Bielefeldt May 9 '11 at 13:45
add comment

Thanks to git branches and how they are easily managed, I commit really often. I would say, whenever you add something that you feel is important and that might add up to building something later, you should commit.

Also, I often find myself doing some refactoring and adding new tests before the new code, so for this case I commit for every time I run the test, watch it fail, make it pass again and refactor.

Also, after any bug fix no matter how tiny or insignificant it might seem.

I sometimes go down the "commit it as soon as it compiles" road as well.

share|improve this answer
add comment

If your working in a team environment with a build server, you'll only want to commit when you've got something that builds. It's very annoying for the rest of the team otherwise :)

share|improve this answer
add comment

Watched this Joel On Software - FogBugz/Kiln presentation recently and think it relates well to your question.

While in some version control 'commit' is synonymous with 'publish' (or 'give pain to others') in distributed VCS they are often seperated.

So when to commit may depend on the VCS you use.

share|improve this answer
add comment

Automatically commit after every successful build.

I assume that if you want to revert to an earlier version, and you can remember the approximate wall-clock time of the point you want to revert to, you can just look up at that revision.

Of course if you use TDD then there are better integrated solutions.

share|improve this answer
add comment

Every night when I go home I have a script that will automatically go through all my branches and do a commit (note all developers don't get these changes. Its just my personal branch). This way I don't have to think about it.

Also I have a script that will automatically run an update in the morning. I use this one so that if I work from my laptop at night my changes are automatically there in the morning.

As for rolling back changes that I make during the day my editor has a history of all changes and is much faster than doing a commit on every save/compile.

share|improve this answer
add comment

I work alone. My development environment is my notebook. The commit environment is a server on the web.

If the client uses the web server to keep track of progress. So nearly every day I do an upload along with an e-mail saying what's new.

If the commit environment is a production environment then I have to be more careful about every change being tested before any commit. But still, often seems better, as nobody has doubts about whether the new feature is planned or done already; they get what they ask for ASAP.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.