Sunday, September 12, 2010

My first dose of Git nirvana.

After using Perforce and CVS for years, I've spent the past two weeks using Git for our startup.

It only took a few days to get semi-comfortable using Git in the centralized model. I.e. I'd do some work and submit it to our central repo, rinse and repeat.

Until today.

I wanted to add a third party library to our system, which entails adding src & binary jars to /lib, and adding references to it in our ANT build.xml and shared IntelliJ project. I.e. just housekeeping work. So I did that locally and committed it to my local Git repo. I thought nothing of it. Now my working dir was clean, with no modifications.

Next I started using the third party library, adding some snazzy functionality to a demo. A little code here, a little there, and I was ready to commit again. Now I committed a second atomic changeset containing just this functionality and nothing more.

What's funny is that the whole time I was on VPN and could have submitted to our central repo, but why? Aside from the risk of my hard-drive melting down (unlikely and not a concern for 30 minutes of work), Git already had my commits tracked perfectly. So after completing these two bits of work, I pulled from the remote repo (with zero merge conflicts), and then pushed back my repo. That's it. Now everything is in sync, and my changes show up separately in our central repo with their independent commit messages etc.

So in summary: Even without doing wild distributed development, branching, etc, Git is extremely useful to isolate and track changes that compliment each other. Even without an explicitly named branch, you can complete several small chunks of work and push them together and atomically to a central repo. Great stuff!

No comments: