Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a sole developer at my work and while I understand the benefits of VCS; I find it hard to stick to good practices. At the moment I'm using git to develop mostly web apps (which will never be open sourced due to my work). My current workflow is make lots of changes to the development site, test, revise, test, be happy and commit changes, and then push the commit to the live site (so if I'm working on a big new change; I may only commit once a week; but my IDE has a good undo history for uncommitted stuff). Basically, I'm only using git when switching between machines (e.g., work dev computer to home dev computer or to live machine), but during the day I don't really see the benefit. This leads me to have long laundry lists of changes (and I have trouble finding good msg for each commit; and whenever I'm in a rush - I tend to leave crappy messages like 'misc changes to admin and templates').

How often should I be committing? Should each one-line change get a commit? Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)? Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh? What I am missing out on by having bad VCS habits?

share|improve this question
Maybe one of your hangups of why you feel like VCS doesn't work for you is because you are using Git as a solo developer? Git seems like overkill to me for a single developer, perhaps something simpler with less features like SVN will be easier to use? – maple_shaft Jan 10 '12 at 18:09
@maple_shaft: I haven't used Git, but Mercurial is about as simple as Subversion for basic solo developer tasks. (Simpler, actually, since creating the repository-equivalent is easier.) – David Thornley Jan 10 '12 at 18:26
Why would git be overkill? – Tamás Szelei Jan 10 '12 at 18:30
Commit often, use branches and use tags. Related question. – Tamás Szelei Jan 10 '12 at 19:04
It's worth mentioning that for DVCS like git and mercurial, to reap the benefits of an offsite backup of your source control (as mentioned in some of the answers) you'd need to push regularly, not just commit. – tugs Jan 10 '12 at 23:16
up vote 17 down vote accepted

You are missing a lot.

I'm solo too, in a way. I commit every time a make a significant change, or before I start a significant one so I can go back if I screw things up, and every now and then even if I'm not making anything big. Not everyday really, but close. Sometimes a few times a day.

What I get is that I can go back anytime I want. Which is a lot. Also, having the branches ordered helps.

I guess it gives me a lot of order.

I'm using svn, and I'm getting sick of it. But cannot spend more time learning anythings else.

Good luck.

share|improve this answer
+1 I have recently started using VCS myself, and GIT is the thing for me :) – yati sagade Jan 10 '12 at 18:12
I had avoided version control for a long time as I was under the impression that it was too bulky/ugly/annoying. A few months ago I decided to get familiar with Subversion and now I swear by it. – Dalin Seivewright Jan 10 '12 at 19:13
I have several solo projects: some on Github, some not. I always use git even if I'm just building something for the express purposes of learning a particular API/tool. It enforces good habits for the real projects where it is more useful, as @jbcolmenares describes. – sarumont Jan 10 '12 at 19:34
I'll counter your "cannot spend more time learning anything else" with Count the time you spend being angry at svn for one week, then take that amount of time to read hginit the next week. – tdammers Jan 10 '12 at 20:25
@tdammers will take a look – cauchy Jan 11 '12 at 19:39

You should commit often. You should certainly commit after reaching some logical milestone. If that takes longer than a day, you should at least commit at the end of your work day, or better yet, break up your work into smaller chunks.

There are many reasons for doing that. For example, what if your computer crashes? It is much better to lose only a day's worth of work than a week's or a month's. Another reason is that frequent commits make it easier to isolate a bug. You can do a binary search and figure out which small change caused the bug.

Another thing: before you commit, you should do a diff and look at all the changes you have made. This allows you to check that all the changes make sense, and that you have not forgotten anything. This also helps you to come up with a better commit message. And, of course, this is another reason to commit often: it is much easier to go through a day's worth of changes than a month's worth.

share|improve this answer
"what if your computer crashes" - files are saved to disk quite frequently and backups made nightly (if you meant if the hard disk breaks). However +1 for the binary search for bugs could come in handy. I'm pretty good at quickly finding 95% of my bugs; but every now and then there is the truly bizarre bug arising from a seemingly inconsequential change in another part of the program. – dr jimbob Jan 10 '12 at 20:10
Yes I do mean "if the disk breaks", or "if the ceiling caves in", or "if an EMP device goes off nearby". :) Anything that may cause a loss of data. Committing often is the easiest way to back up your work, and it allows you to easily have an off site backup, by using a remote version control server. – Dima Jan 10 '12 at 20:26

To get the most out of CVS you should work on one feature/bug-fix at a time, and commit when that feature/bug-fix is complete. By doing this you'll gain:

  • commit messages will will be easier to create and will make more sense;
  • easier tracking of future bugs back to the changes that introduced them;
  • easier reverting to a previous state (even if that means losing a failed feature but keeping bug-fixes that occured afterwards).

Also, since you switch between PCs you should have at least two branches:

  • a "Ready to go" branch that always works (excepting the bugs you are working on in the development branch, of course)
  • a development branch that may be in an unrunnable state from time to time (like during your trip home from work ;) .
share|improve this answer
+1 for the ready to go branch! I don't know how many times I get asked to show the software as the boss and prospective clients walk by. It is nice to have a version that actually works and not in a state of flux. – bluebill Jan 10 '12 at 23:26

Should each one-line change get a commit?

If that is what fixes a bug, sure.

What I am missing out on by having bad VCS habits?

I worked with a guy who had "bad VCS habits". He loved to work all by himself and he was in charge of a product line that brought in something like $1,000,000/year. He'd only make committs when the boss nagged him. Then one day his hard drive crashed. After getting a replacement set up for him, we discovered his last check-in was 6 months previously. Since the VCS was Source Safe, you can guess what else went wrong - the last commit was corrupted. We had to go back more than a year to get a non-corrupted version of his product line. He didn't get fired, even though he should have been.

Another anecdote involves myself. I used to store code for hobby and research projects on removable hard drives. One day, my apartment was broken into. The laptop (which was broken) and all the removable hard drives were stolen. Every DVD (with the exception of Red Dawn) was stolen. None of the desktop computers were stolen. If I had offsite source control, I would not have lost 15 years worth of projects, especially since some were based off academic projects - many of the profs left academia to go to private industry so those projects vanished into a corporate IP black hole making the lost code impossible to recover.

How often should I be committing?

I break it down into a few metrics:

  • How much work are you willing to lose if your computer dies? or gets stolen?

  • If this fixes Bug_1234, then check the code in with the comment "fixes Bug_1234".

  • If this is a logical delivery/milestone, then check it in with a comment like "Bug_1234, form_xyz" (or Task_1234 as appropriate).

  • Always check in code on Friday evening before you head home. Also do a check-in (or undo the checkouts) of everything before leaving on vacation.

  • Whenever the company policy dictates.

share|improve this answer
+1 for having a copy of "Red Dawn" :-) – Ross Patterson Jan 10 '12 at 22:43

I'd say the biggest thing you're missing out on by grouping changes together like that is the ability to track down when and where bugs were introduced.

In my experience, there have been a couple of times where some bug is noticed two-three weeks after it was introduced and having to sift through a week's worth of commits is difficult that long after the fact. In these cases, it was helpful to simply binary search through the commits to track down which individual change caused the problem. These bugs were mostly memory usage bugs on C++ code, so it may not happen as often for your project.

Other benefits come into play when developing on a team - simple commit comments, easier merges, relating commits to bug fixes, etc.

I'd guess with your workflow that if you do start committing daily or semi-daily, you'll need to use tags or bookmarks to keep track of which version of code is in use on the live site. I'd say that's the most important thing to keep track of.

share|improve this answer

I am a solo developer too, I use SVN, and I love it. I have even written a tool to convert the structure of my database and the test data in it to xml so that I can include that in source control.

I usually commit whenever I have completed an autonomous unit of work. Sometimes, if I perform a bunch of trivial and unrelated single-line fixes here and there then I commit all of them together, but if a single-line fix happens to occur between two unrelated big autonomous units of work, then it gets its own commit, there is nothing wrong with that.

Also, I always commit code which compiles, and almost always code which also passes all the basic tests. If not, I make sure to include "DOES NOT WORK" in the commit message. The only case when this happens is when I have done important changes which I do not want to lose even though they do not quite work yet, and on top of this I am about to embark in a great refactoring adventure that I am not sure whether it will be successful. So, then, I use the repository as a backup of the work I have done so far before risking to mess it up and have to throw it away.

This means that I always commit when my source code needs to be committed; it makes absolutely no sense to have morning commit or evening commit rules. It is the state that the code is in which dictates whether or not it is time to commit.

The messages that you put in the repository do not matter much. If you absolutely cannot come up with something meaningful, it is still better to commit with a blank message than to not commit at all when you should.

If you can't think of a good commit message because everything you come up with sounds stupid, bear in mind that this is okay; commit messages are expected to state the obvious, so they are bound to sound stupid to you when you are writing them. But trust me, if you need to examine old revisions a month later you will be grateful for even the stupid messages over no messages.

share|improve this answer

Do not think in terms of number of lines changes. Think in chunks of functionality. VCS allow you to give a heading in a central place for each functionality chunk so you can easily see the "what has happened here" with e.g. git log.

Also, IDE's like Eclipse allow you to point to a given line and go to the commit that brought it into the shape you see. In other words, you can go directly from a source line to the commit. If the commit is small and has a good message, it is much more helpful than "fixed tons of bugs".

share|improve this answer

How often should I be committing?

As a solo developer I generally commit whenever I feel I have made a significant change, after basic testing, and when I leave a project at the end of the night.

Should each one-line change get a commit?

No, unless that one-line change is going to significantly change a feature or bug.

Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)?

Probably not. At least for me I do most of my testing and coding on a 'working copy' and commit after I am happy with my changes. In many IDE's it will show me what changed before I actually make the commit and give me an opportunity to attach notes to the commit

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh? What I am missing out on by having bad VCS habits?

I am not very familiar with VCS or what bad habits it causes. I think I have mostly shared my opinion on this in answer to the first question.

In response to the general question postulated, you seem to be mostly using commits as branches which is addressed in another responders post. I'm not sure which IDE you are using that has a good undo history etc, but I haven't found one that I felt was good beyond restarts of the IDE and moving in between machines.

share|improve this answer
I am not very familiar with VCS or what bad habits it causes. Lucky you! – Yannis Jan 11 '12 at 8:32
I'm not sure how I read that incorrectly multiple times, but I kept reading that as 'VSS' as in Visual source safe. I am fairly familiar with some different version control systems including SVN and GIT and use them as a solo developer frequently, but probably have a few bad habits myself considering that I haven't really used them in the context of a large multi-developer scenario. – dbuell Jan 12 '12 at 23:24
Well, as I've battled with SourceSafe for more than 3 years, my comment still stands: Lucky you! To give you an example, VSS6 could handle repositories of about 200mb - 300mb, after that if you were lucky a few files would be randomly corrupted. Of course there where multiple fixes, and workarounds, and VSS was never intended by MS to be a full blown vcs, but consider yourself lucky you never had to deal with it... – Yannis Jan 12 '12 at 23:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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