1

I am trying to explain the benefits of version control to a colleague (recent graduate with little software experience), but he doesn't think it is useful in his case.

I explained you commit every time you write a new function, fix a bug, or generally add anything useful to your code. The stuff he is working on started out not working, and all his changes are just attempts to fix problems (some of which are hardware limitations)

Is there a good general rule for how often to commit when you code isn't working? Normally, I try and not commit too much stuff that doesn't work, just when I stop working for a day, but if you are going to have long periods of code not working how often should you be committing?

MikeS159
  • 121

3 Answers3

4

I think a good guideline for your coworker might be:

How much of this would you be willing to re-write from scratch if your workstation suddenly exploded (and you lost all work since your last commit)?

Of course, it might depend on how badly it "doesn't work". If it won't even compile, maybe ask him to avoid committing that until he can resolve compiler errors.

FrustratedWithFormsDesigner
  • 46,335
2

What version control system are you using? The popular distributed version control systems such as Git or Mercurial distinguish between committing and pushing, whereas SVN (Subversion) does not.

The important part is what commits end up in the shared repository. Ideally, no commit that breaks compilation should ever be pushed. And the application should also run, otherwise just by pushing you halt other developers. And, ideally, all the test should pass, especially the ones what was there before.

Before pushing, in many DVCS like Git, you can do whatever you want, but I strive for the same as above. But you can commit broken commits, and then modify them later to one or several nice commits. Sometimes I make broken commits and push them to a separate server, if I need to continue working on another computer. Then I modify the code, and when it is done I undo the broken commit, and make one nice commit.

You can also use different branches, like feature branches, so developers can work on different parts of the system, and push without disturbing other developers. Then when the feature is done, everything compiles, all the tests pass, you can merge the commits into a main branch.

But the best solution to having long periods of code not working is to never get into the situation. Get to a situation where everything works. From this working situation, try and divide the work into smaller incremental changes where each change results in ending up in a new situation where everything still works.

senevoldsen
  • 290
  • 1
  • 5
0

From a version control perspective it is pointless to check in "versions" that do not work. A version should be a state of your working product. Of course it is up to you to abuse your VC system as a means to backup your work but I would regard that polution.

Some benefits:

  • It allows you to track incremental changes made in the past (by change number). This is particularly valuable when you are not the only one working on the product.
  • It allows you to "pin" or "label" multiple states of your product that you can later easily go back to if you need to, for instance to reproduce a problem reported by a client that is using a particular version.
  • It brings transparency to the development team.

It is hard to make a strong case for VC when there is only one person maintaining the code. Scripts that make zip files and create sandboxes from them go a long way. In a multi-developer environment however there is no serious alternative.

Martin Maat
  • 18,652