Late Adopter

I'm a late adopter of almost everything. Being a long time "windows guy" I typically wait at least 2 years after a new version of windows is released before upgrading. I am on Vista currently only because it came with my new PC, if not for that fact I'd be still slinging XP. The only reason I'm on Windows at all is because of gaming and my inherent laziness to create a dual boot system. Things have changed recently though, when I got the new PC it did not come with video card, it was onboard, and not anything I could play a modern game with. So this means I haven't played a PC game since approx. Dec 27th (not that I'm keeping track or anything Image may be NSFW.
Clik here to view. ).

Because of my previous contracts, I've been developing on Windows exclusively. My choices were usually limited by corporate standards, lack of Linux vpn client, etc... But with my current contract I have a choice, so what I've done is I've been running Ubuntu within a VMWare session on Vista. I really like this option for two reasons:
# I can backup my entire development environment, OS and all, by simply copying the VMWare image file
# If I need to work from my laptop, I copy the image over and I am up in running in a matter of minutes in the exact same environment (no saying "oh crap, tool XYZ isn't installed")

git, a different animal

So.... getting back to the subject, I don't typically change unless I need to. I've been coding Java for roughly 8 years, prior to that it was VB. I tried RoR, but never really got farther than admireing Ruby's closures. That's the trouble, when you are developing professionally in a language and wish to "switch" it's not like you can just go out onto the market and say "I'm a Java developer looking for a contract that teaches me RoR". It just doesn't work that way, people want you to come in on a contract hitting the ground running, not crawling. Same goes for version control systems, you use what the corporation paying your salary uses. Sure you might oggle the features of some other VCS, but unless you have a set of personal projects you can use it on, you aren't going to get to know that other system.

Sure you can learn things "on your own", in your "spare time" (does such a thing exist for some people?) but unless you do something like contribute to an OSS project, or create a publically facing app, you won't have the experience to go along with your self teaching. I have found experience is what sells you out in the market.

git is different though, git allows you to use it without anyone else knowing you are using it. That's a great feature, it's almost like if you were able to write your code in Ruby/Rails and just prior to commiting you run the magic program which converts it to Java. You get to learn the ins and outs of a new framework and someone else pays you to do it. What I've been able to do with git is clone my client's svn repository into a local git repository using git-svn and commit/branch against the local version. This is great because I can work on several features at the same time, and when one is ready to be promoted up to the svn repo, I can commit only those changes I made to my local "feature branch"! When I'm done committing the feature I was working, I switch out of it's branch, execute a an @git-svn rebase@ in my other feature's branch, and continue my work.

The above reasons contribute to why I'm a relatively early adopter of git (at the insistence of Marc and Alex mind you), for the simple reason that it's unobtrusive.

The Changeset Shuffle

> svn stat
? com/mycompany/feature/new/SomeNewFeature.java
M com/mycompany/feature/old/SomeOldFeatureThatNeededFixing.java
M com/mycompany/common/SomeCommonClassModifiedByBothFeatures.java   <--- Ah crap!
> cp com/mycompany/common/SomeCommonClassModifiedByBothFeatures.java SomeCommonClassModifiedByBothFeatures.java.new
> vim com/mycompany/common/SomeCommonClassModifiedByBothFeatures.java <--- remove the new features
> svn ci -m "qa fix 10032"
> mv SomeCommonClassModifiedByBothFeatures.java.new com/mycompany/common/SomeCommonClassModifiedByBothFeatures.java

git really helps you in those times where you are working on some new/experimental feature and then are hit with a critical bug fix found during a QA cycle. Instead of doing the "change-set shuffle" ; you know, when you are frantically trying to figure out which files should be commited that were part of the fix and which were part of the experimental stuff ; you instead just "stash" away the experimental stuff, or branch your master and fix from there. I know you SVN'ites are going to tell me "but I can branch just as well as you can!". This is true to some extent, however with git I can do it without cluttering up the remote svn repo with a separate branch for the change. Using git I can easily and safely from the comfort of my own machine, branch, fix, commit a change and reconcile it to the remote svn repo. All of my git commits, all of the comments I made for those commits (you do comment your commits right!) all get pushed up to the svn repo. Beautiful.

How to learn

Marc put me on to PeepCode specifically their excellent git intro screen cast. I'm very much a visual learner, so the screen cast format was an excellent choice for me. You can keep track of some of the other resources I find helpful with git, by taking a look at my del.icio.us links.

In conclusion...

I find git really rocks because:

• I can use it in a corporate environment that doesn't support it

I can't do that easily with other VCS

I guess the one gripe I might have is that instead of revision numbers, git uses "hashes" to mark an atomic checkin. I don't know about you, but I am constantly asked at work "What revision was that changed checked into?" It's a lot easier to answer "rev.381" than to say "rev.9a02133e6f288864bc6bc9b18ec01732649892h3"

I think Marc said it best, you have to try it in order to have that "a hah" moment, so go out and try it! Need help? Let us know on freenode in #basementcoders, or leave a comment right here.