Best version control habits for solo developer?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 ;) .

Answer 4

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.

Answer 5

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".

Answer 6

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.

Answer 7

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.

Answer 8

Commit each time you do a "logical" change. For example if you're implementing a new feature, you're doing it step by step. Each of those steps usually depend on each other. So you can just commit those steps separately, and explain in the commit message why each step is required.

The commit message is really important. You must avoid telling what you're doing, tell why you're doing it. The code already documents the changes, but in 6 months you'll be happy to see why you did them.

This is also useful if by chance someone jumps in and you're not alone anymore. Even just for you, a clean history makes it easier to use a git blame to know when and why that line that has a bug has been changed.

Making small commits instead of big ball of mud changes also allows you to test the intermediate state. You can stash the changes if you have to release something urgently. If you introduce a bug while it worked before, you can stash and check if it's your uncommitted changes that introduces the bug, or if that was in an older commit.

You can also unleash the power of git bissect that will tell you the commit that that this nasty bug. If the commit is 2,000 lines long, it still helps but not that much...

Another thing is that it's the first step for continuous integration (CI) and then continuous deployment (CD). CI and your tests can be triggered on a new commit, hence telling you each time you push your changes if they break something or not. This way you can know if it's safe to deploy or not, and be notified of that at the moment the problem is introduced and not just before your release when you're in a rush.

About your other questions:

• don't commit stuff that you didn't even compile, unless you're willing to rewrite your history for that (using git rebase --interactive).
• a one line change deserves a commit if it has a separate purpose (fixes a bug, or is unrelated to your currently uncommitted changes). Use git add --patch to stage those.
• no need to force yourself to commit before dinner, unless you have important stuff you can't afford to lose. In that case, you may want to commit in a separate branch your work in progress.
• committing and pushing to a remote repository is a backup. If you commit and push only once a week, you can in the worst case scenario lose one week of work.

Answer 9

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.

Answer 10

I'm a habitual committer and I found that suits me, but admittedly my commit messages are almost always like,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

So I can't exactly say that making such frequent and habitual commits to my branch (mercurial) has exactly encouraged the most detailed commit logs. Sometimes I'll even commit code halfway done if, say, my wife asks me to go out for dinner at which point I'll just hastily copy and use the previous "Working on [...]" commit message.

My commit log patterns are typically like, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

On the flip side though, it has saved my butt. Sometimes I do run into an edge case I didn't anticipate and test against, at which point the frequent commits help me figure out exactly where I introduced the mistake.

So I don't know about the best habits and I'm certainly not one to listen to as far as ideal commit logging habits, but I can certainly say that committing more frequently can definitely help out when you need to perform a regression.

Should each one-line change get a commit?

I've committed one-line changes before but usually tricky ones and maybe I was short on time. My commits don't always resemble perfect and complete units of work or change. As said, sometimes they're just the result of my wife asking me to go out for dinner unexpectedly.

TBH a lot of my commits which follow that "Working on [...]" log pattern are not modeling coherent units of change (why I often cannot come up with a message better than "Working on [...]") but just the result of me taking a breather, like making myself a cup of coffee. The "Completed [...]" message indicates the end of that unit of work, and there I often write a much more detailed message along with the first "Started working on [...]" type messages when I just start working on something. If you average commits like once every 15 mins, then those "Working on [...]" messages are more like in-betweeners for what someone might commit in one bulkier commit with a more detailed message.

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

I just go ahead and commit it before even running tests sometimes (again if I had an unexpected event). Also even though I'm solo, I do push to a server (just one running here at home on a LAN) that does CI. That might seem like overkill but dunno, I got so used to leaning on that in my former workplaces. Plus I don't wanna be bothered having to run all my unit and integration tests by hand each time. I like having that all tied to just pushing. If a test fails it's easy enough to work in a forward-moving fashion where I do the regression, correct the mistake in the latest rev, and keep going. That said, I do at least build the code against a debug build before I commit.

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh?

I like to commit before I go out and have a break between programming. I didn't really put much thought into why exactly until I encountered this question. I suppose it's to prevent myself from picking up where I left off without a commit log there in place of where I left off that I can diff and so forth. Hmm, I need to get back to you on that since it's maybe not theoretically needed given how frequently I commit. I still feel more comfortable committing and pushing before I leave the computer for whatever reason. Some of it might be that former psychological fear of, say, the computer catching on fire after I leave and having project managers back in the days when we were using SVN with the devs sometimes going for weeks without commits breathing down our necks and constantly reminding us to check in code as often as possible while reminding us that our code is the company's property. Also it's a little bit more efficient especially with the pushing so that my CI process can start running all the tests while I'm away so that I can come back and see the results.

Oh and sometimes I get a bit drunk after I leave and it's usually a bad idea to try to write complex code while drunk (though not always; one time I came up with a really nice context menu system after having an eureka moment while drunk, but I only had like 6 beers and it wasn't that complex to code). If I attempt to do that, at least I committed the soberly-written code before I left to revert back towards instead of mixing the drunk code with the sober code, at which point my commit log might read like, "Reverting back to code written before Jagermeister shots." I don't do this very frequently unless I got a drunken code inspiration, but in those rare cases, it really did help that I committed something before I went out and got drunk.