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.

Background

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.

GIT FTW
— Doug

My goals

This past year, I have read many discussions about the pros and cons about distributed version control systems (DVCS), and git in particular. It seemed like it might be a better fit for the style of development I have been doing the last few years, but since our current process worked well enough, it wasn’t worth the bother to switch at the time.

But, I was intrigued, and decided to use git in a project sometime soon, and even though my new project is a solo project at the moment, it gives me to get accustomed to git.

I had some pretty fuzzy goals when starting:

1. Use git for version control
2. Integrate git with XCode as much as possible
3. Setup separate physical machine for a remote repository

And at the time, I wasn’t quite ready to begin, so I gathered my thoughts into a simple project on Things. (Things deserves a post of it’s own — very useful, flexible, and straightforward.)

Setting up a new server

Fortunately, since I wanted a remote repository on physically separate machine, I had an old pc sitting around that had not yet been completely scavenged.

A friend of mine recommended Ubuntu, so I decided to try it. I retrieved the latest installation image, Ubuntu 8.10, burned it to cd, and installed. The installation went without a hitch on my 4+ year old machine, thanks Paul!

Setting up a remote git repository

Ubuntu does not install ssh or git by default, so I installed them both from a terminal window using apt-get.

$ sudo apt-get install ssh
$ sudo apt-get install git-core


I have used subversion for years, but am new to git, so I googled for some tips. The article ‘Remote Git Repos on Ubuntu: The Right Way‘ was very useful. I followed what Drew discussed and had no issues at all, and I was now two for two.

XCode and source control

XCode comes with in-built methods to deal with some source control systems, but nothing for git.

Git for the Cocoa Developer: A Typical Workflow describes how Christopher Roach setup his git project directory. Since I had followed Drew’s steps for configuring git, I really only needed to use the configuration information for ‘.gitignore’ and ‘.gitattributes’ described in the section ‘Config the repository for Cocoa development’.

I had an existing xcode project that I wanted to put into git, so I followed these steps:

$ cd myproj
$ git init
$ vi .gitignore

I then reopened my project in xcode to make sure I did not break anything. (It was fine.) I’m sure I will be fiddling with ‘.gitignore’ as I move along, but for now I’m calling it good enough. Obviously, since xcode is unaware that I am doing version control, I will have to manage that via the command line or other tool. Since this is as much a learning project for me as anything, I’m okay with that for now — but I reserve the right to vent here later!

Over the last couple of months, I have been working on a set of ideas for a new iPhone application and have actively begun development today. As I begin narrowing down my thoughts on features, I will post more about the actual application.

My current goals:

• Focus on doing a few things very well,
• Link to existing resources where it clearly enhances the value of the application,
• Deliver a working application to a small set of people by February 2009,
• Have a marketable application by April 2009,
• See continued growth in customers each month of 2009.

I have spent a considerable amount of time the last two months reading books, articles, blogs, reviews, etc. to get a better understanding of what it takes to build a business around an iPhone application. I have not done enough to be comfortable (who has), but I have done enough to begin.

Today’s accomplishments:

• I successfully upgraded to the latest versions of all the tools,
• I downloaded what appears to be useful sample source code,
• I verified that my development environment works as expected,
• I applied for Apple’s developer program (thought I had done that months ago),
• I restarted my blogging with this post.

Next tasks:

• Figure out how how to best use GIT with xcode projects
• Setup a GIT server on a separate machine,
• Acquire one new skill with iPhone SDK
• Post about my progress.

Waiting on:

• An e-mail from Apple about the developer program