GIT to the rescue

I recently completed some short term Java work where using git saved me quite a bit of work. The real savings came about because of the style of work that a distributed version control system allows you to follow: many small commits with easy branching and merging.


Most of my work lately has been doing Java work remotely on my own machine. The projects use Ant scripts for the build process and Subversion for version control. I was used to having access to customer VPNs from my machine, using their servers for database access and version control.

All of this works pretty well for me and my customers, as it does for many developers today.

Recently, I picked up some short-term work to add undo and redo functionality to an existing Java Swing application. The project uses an older version of Rational ClearCase for version control, but circumstances did not allow them to use the web component of ClearCase. Also, company policy denies access to the VPN from non-company computers.

The work itself did not require a lot of interaction with the rest of the project team, so most of my work could still be done on my own if I could figure out a reasonable way to access and update ClearCase. I am perfectly willing to switch development tools or equipment if that works best for the customer, but since this was a short-term project, I knew I would be much more productive if I could keep my work style as unchanged as possible.

I had been using git for some personal projects, and thought it would be a good choice to support my work. I checked out the current project view from ClearCase on a company machine, copied the files to my machine, and setup a local git repository for it.

I was then able to use git to make many small commits as I worked on the project. When I was in the office, I would copy over changed files from my local machine to my ClearCase view and update the company repository with my changes. The process worked well and I was able to stay productive most of the time.

Git to the rescue

Early in the process, I introduced a small bug that had no effect in my development environment (a MacBook Pro), but ended up with some screen update problems when running under Windows XP. I did do sanity testing on the GUI on a Windows XP box while in the office, but did not notice anything odd until two weeks later.

By that time, it was not at all obvious what kind of change could have triggered the problem, and I spent a fair amount of time investigating double buffering, validation, and other Swing differences between the Java VM on OS X and Windows. After probably too much time on workarounds and checking Swing internals, I decided to give it a rest for a day or so and then use my git history to help me track down what change caused the problem.

When I came back to the problem, I started with a copy of the project directory and basically did a binary search through all the commits to find the one where the bad behavior started. It took a little over an hour to find the change that caused the problem — a bug that might have taken many more hours to find using any other method.

I am so pleased with the results that I will be using git and the style of many small, local commits, in every project I possibly can.

— Doug