Version control and the single developer
November 14, 2012 in Technology
I routinely chat with solo developers, and eventually we talk shop, and the subject of version control comes up (OK… sometimes I bring it up!). I’ve noticed a trend in the past couple years of solo developers more and more not using any sort of version control, and something about that bothers me, although I can’t quite put my finger on it. It may be because the majority of people I know not using it have never tried it in the first place, and are missing out on a lot of benefits based on myths or misconceptions.
Common justifications I’ve heard include “Well… I’m just a single developer, I don’t need it” and “I already have backups running”. This demonstrates a real lack of what benefits version control offers, so I thought I’d share a few of my own reasons why I use version control.
Branching
Branching allows me to develop different sets of code on the same computer without fear of losing or overwriting code that I’m not sure I may need to keep or change.
Specifically with git, this is extremely fast and easy to do. The idea of branching is to create a parallel code tree forked/branched from a specific point in your main codebase, and work on it without disturbing any of the code in the main codebase (or.. the main ‘branch’ if you will).
Subversion offers a type of branching, but if I remember correctly, it essentially involves making copies of all existing files. When branching in subversion on large projects, this can sometimes take several seconds or even minutes (2006/2007 I recall some large projects taking > 3 minutes to branch on the hardware I had). This can severely interrupt your flow when working, and once you experience branching in git (or similar functionality in other distributed version control tools like mercurial) you’ll wonder how you ever survived with subversion.
Visual progress / transparency
Most of my clients aren’t technically savvy enough to read code, but they can still watch progress in my version control repository – they can read commits and see what problems I’m working on, even when what I’m working on isn’t visual or front-end related. I don’t use this in place of issue tracking or written and verbal status updates, but it’s another data point they can look at to validate I am in fact working, even when it’s not apparent. Additionally, they can have someone else look at the code and changes to verify I’m actually doing what I say I’m doing and doing it properly. Have I ever had anyone do this? I don’t think so – my clients tend to trust me (and vice-versa) but the option is there – there’s no secrets as to what/how I’m doing on the project.
Collaboration
Even though 95% of the dev work I do is on my own, by having everything already in a version control system, getting assistance from others is that much easier because they can grab the repo code and dive in. ”yes, but you can just send your code to them”. I can, but they can’t see my progress or history to know what I’ve tried and not tried. When they want to send back a fix for me, they can branch and push a separate branch for me to review and test before merging in with my other code. It’s far cleaner and faster than emailng around source files and diff patches.
If you’re using version control as a solo developer, what do you use and why? If not, why aren’t you using version control? Does it seem too cumbersome? A waste of time?
Marc F. Spina said on November 14, 2012
Great post Michael. I was one of those solo developers who didn’t use version control. I was always planning to but never got around to it. However, after we had a phone conversation a while back and you turned me on to bit bucket, I committed to start learning Git.
I now have all my active projects in Git and I can’t express how much easier it’s made my life. Initially I started playing around with it in Windows, but subsequently changed my development environment entirely to Ubuntu Linux. I find using Git on Linux is much more intuitive since there is only one terminal.
I have one machine on my LAN which acts as my “server”. I’ve initialized repos for each project on this server. I then pull the project from onto each of my 4 development machines. At the end of each development session, I commit and push changes to the server. It makes it extremely easy for me to ensure that I always have the latest version of the project on each of my development machines. In some cases, I also setup a repo on the production server, and add it as a remote to the dev machines. I’ve setup post-receive hooks on the production server to copy the latest branch into a working directory. Then when I push to the production server, it updates the working directory automatically. I find it’s a quick and easy way to deploy some projects without having to mess around with FTP.
It’s also helped me become much better at interacting with various servers using the command line. Certainly I’m no expert, but as a direct result of learning Git I’ve become functionally proficient in using the command line to SSH into remote servers and perform a number of other administrative functions.
I still need to spend more time using git hosting services such as bit bucket but I can certainly say that for the time I’ve invested learning, the flexibility, ease of branching, and other features have been well worth the investment. I can’t speak for Subversion but I would highly recommend Git to any developer.
Michael Kimsal said on November 15, 2012
I’ve looked at self-hosted gitosis and others – I think there may be some new updates to a few that I’ll reinvestigate, but for now most of my projects are on bitbucket (for the expanded private repos) and github (for most public repos). github was an original sponsor of indieconf, and I’ve got a special place in my heart for them for that, but bitbucket’s free private repos are hard to argue with.
As for command line, I’m a solid tower.app user for 90+% of my git needs, but can ‘git pull’ with the best of them from a command line when needed.
Rodney Weis said on November 15, 2012
I’ve used both Git and Subversion in freelance group projects, but not as a solo developer. Until now – thanks for the kick in the seat to get up to speed. Even on small-scale personal and client projects, I can see where there would be great utility in keeping track of progress and having the ability to branch. I like Marc’s idea of setting up a LAN machine as a server for local development. Although I’m already on Github (not actively, which will hopefully change as well), I was not aware of bitbucket – thanks for recommending them, I’ve just signed up. Since I’m developing on Windows and Linux (no Mac? gasp!!), I’ll likely stick with the command line rather than get involved in a GUI.
Thanks both Michael and Marc for the encouragement to take the leap forward!
Michael Kimsal said on November 15, 2012
Cool! glad to hear it – I will say that tortoisegit on windows is bearable for a lot of basic commands. Would love to see a nice gui tool for windows/git.
Rich Harrison said on November 15, 2012
First, great post and comments on the thread. Its nice to know that I’m not the only freelance developer that uses versions control on my projects!
I’ve been using some form of repository based version control for my development projects for years. Yes, it was a pain to make the leap from “home grown” file naming conventions and daily/weekly/milestone zip files to actually setting up a repository on my network and doing the initial build. However, the ability to search back through different versions, see what I’ve tried and revised and finally selected for the implementation or bug fix was worth the initial pain. There’s also been a reassurance knowing that I can revert back to a known and (hopefully) working state that has encouraged more experimentation since backing out all of those changes is a simple as reverting to a previous edition.
With the proliferation of hosted solutions, and in particular, FREE hosted solutions, there’s absolutely no reason for an independent developer to not be using version control. However, I think there is also a perception among a lot of freelance developers that haven’t worked in a team environment that version control is much harder than it needs to be and is only for “larger” projects.
Now, here’s a couple of questions for the thread:
1 – Besides source code, config files, etc, what else do you put in your repository? (self confession – I’ve been told I put “too much” stuff in my repositories =:^)
2 – Do you tag development builds, milestones, releases, bug fixes, etc?
3 – Do you build your deployments from your repository or from your development environment on your development machine?
4 – Are you using Continuous Integration or executing any kind of code analysis or test scripts, etc. on check-ins?
I’m not doing all of these “yet” but I’d like to think I’m moving in that direction.
Rich
Michael Kimsal said on November 15, 2012
1. mostly just source
2. loosely tag when i remember – not disciplined enough on all projeccts yet. git-flow has helped.
3. generally build from repo
4. i was – need to re-setup on new projects. jenkins likely.
Shawn Davis said on November 21, 2012
I am astonished at the number of solo developers I encounter that still don’t use version control. These days it’s like finding a web designer that still uses tables for layout. Regardless of the many benefits, using version control is simply a matter of professionalism.
Harry Park said on December 16, 2012
I use git for my own projects and really love it. The ability to branch and save stashes gives you freedom to explore stuff without regard to the pain of putting it back to where it worked before.
I also love frequently checking stuff in so i can do a ‘git log’ on my project and see if I’ve been making continuous progress or not. That’s a positive feeling.
Bitbucket is pretty sweet to have free private repos.
Michael Kimsal said on December 16, 2012
I must confess I don’t actually check my git log all that much, but I do know it there if I need it or not. +1 on bitbucket