103

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?

Improve this question
1
  • I commit every half-hour. If I've spent 30 minutes writing code, it's worth backing up. I use a pomodoro timer as well, so it's just part of my workflow.
    – Brandon Bertelsen
    Jul 5, 2019 at 19:30

11 Answers 11

Reset to default
97

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.

Improve this answer
2
  • 9
    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, 2011 at 12:14
  • @WayneWerner Me too. I really wish school would teach testing. The hardest part about writing code is testing it
    – Kellen Stuart
    Aug 22, 2018 at 15:48
102

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

What is wrong is committing 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 committer: never break the trunk. If you need to make several commits that are likely to break the trunk, create a branch instead.

Improve this answer
3
  • 18
    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, 2011 at 20:29
  • 3
    +1 for mentioning "to detect the commit source of a given regression"
    – Ida
    Jun 14, 2012 at 2:51
  • 1
    Like your thought about branching. Hadn't thought about it that way before. Saves a lot of back-tracking.
    – SMBiggs
    Nov 16, 2015 at 22:34
13

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.

Improve this answer
1
  • 7
    +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, 2011 at 12:15
12

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.

Improve this answer
10

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.

Improve this answer
6

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.

Improve this answer
4
  • 3
    "... 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, 2011 at 7:31
  • 2
    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, 2011 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, 2011 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, 2011 at 13:45
4

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 :)

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

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