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
  • 4
  • 1
    depends on DVCS or CVCS? – jk. Feb 15 '17 at 15:45
  • 5
    This is what development/feature branches are for. You can commit to them as often as you want to, because they won't break the build. When your feature branch is complete and tested, you can merge it into the master branch. – Robert Harvey Feb 15 '17 at 15:45
  • @RobertHarvey, that is exactly what I said when someone mentioned not committing broken code. – MikeS159 Feb 15 '17 at 15:50
  • @gnat: While I think this is a duplicate of another question, I think the questions "should I" and "how often" are different questions. – Greg Burghardt Feb 15 '17 at 16:03
  • @RobertHarvey I don't think features branches are for committing broken code. incomplete code, sure, but broken? No, I'm not a fan of that. – Bradley Thomas Feb 15 '17 at 20:30
  • @BradThomas: Incomplete code is broken code. What's the difference? At any rate, I never said it was a good idea. Companies do things all the time that are not good ideas, but you do what you have to to make it work. – Robert Harvey Feb 15 '17 at 20:41
  • @GregBurghardt: don't mind, gnat was told so often he should please be more careful when suggesting dupes, but he seems to be completely resistant against this demands, so I don't think he is willing to improve his behaviour. – Doc Brown Feb 15 '17 at 21:57

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,105
  • 7
  • 126
  • 176
  • A version control system is not the only way to make backups so the point you are making is hardly relevant to the question. – Martin Maat Feb 15 '17 at 17:58
  • 2
    @MartinMaat: Even if a user decides to make back-ups of files to nicely organized zipped archives on a shared network drive, a version control system will make it much easier to find or merge the diffs between each "back up", manage and maintain multiple branches of related work, etc... Having had to do all that in an environment that didn't *have* any version control, I feel that proper version control is much better. – FrustratedWithFormsDesigner Feb 15 '17 at 18:14
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
  • 1
    Good answer. You can also use git locally for frequent commits, even if you have to use a CVCS for sharing with other developers. – Karl Bielefeldt Feb 15 '17 at 17:42
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,218
  • 3
  • 30
  • 57
  • 1
    I have upvoted , the only part I disagree with really is "It is hard to make a strong case for VC when there is only one person maintaining the code". There have been many situations as a lone developer where I would have liked to backtrack to a specific version and seen incremental commits to understand what had happened. – Bradley Thomas Feb 15 '17 at 20:33