GIT: The Sweetest SCM Around

Yesterday I asked on the Maven Development list about using a GIT repository as the canonical SCM for Maven 3.x. My reasoning for wanting to use GIT over SVN are based on the following:

* A distributed model
* Network efficiency
* Simple branching and merging
* [JGIT][jgit]: A pure Java implementation of GIT
* [Gerrit][gerrit]: An awesome peer review system based on JGIT

[jgit]: http://code.google.com/p/egit/
[android]: http://code.google.com/android/
[gerrit]: http://code.google.com/p/gerrit/
[gerritdemo]: https://review.source.android.com/Gerrit#all,open,n,z
[nexus]: http://nexus.sonatype.org

### A distributed model

Everyone has a real copy of the repository. This means that you can easily work offline, have real change management locally, easily collaborate with others, and full copies of the repository are in many places. Being able to have an intact copy with full history means that there is no central point of failure and I can happily work and keep collaborating with others while the designated canonical repository is unavailable. Anyone can pull from a canonical repository, or from any developer with a copy of the repository. Commit access becomes a moot point and patches become a thing of the past.

### Network Efficiency

At Sonatype we have a developer in China who always has problems connecting to SVN and updating is quite painful given his bandwidth constrained environment. GIT is very network efficient and really makes collaboration less painful for those where bandwidth is not abundant. I think with SVN this might be a result of SVN being designed and develop in a bandwidth rich environment like SF/Silicon Valley. For the purposes of collaborating with people all around the world an SCM which is more resource friendly is easier for more people to use and should therefore be preferred. GIT provides a network model which I would consider accessible and fair.

### Simple branching and merging

Branching and merging are simple in GIT. No finding URLs to make branches and no digging up revisions (is that r+1 or r-1?) to merge and the strategies for merging just seem to work a lot better. When doing any long term branch with Maven I can't really remember not being frustrated by some aspect of branching and merging with SVN which makes me avoid it and this ends up causing problems on trunk. It's just a lot easier to experiment in GIT with branches and then be able to easily merge in many experiments or parts of experiments. A lot of it is anecdotal but people seem to really like the branching and merging capabilities in GIT.

### JGIT: A pure Java implementation of GIT

Shawn Pearce has done some great work on [JGIT][jgit] which is a pure Java implementation of GIT. This means that I can actually hack the SCM that I use. This just too hard for me with SVN. I could at one point in my life read/write C but I'm just not that interested anymore. I just don't personally find it to be a productive language. Therefore SVN is a black box to me so when something annoys me I'm probably not going to fix it myself because I'd probably eat my own hand off before I'd write in C again. I really think the use of GIT will flourish among the Java community because you can combine JGIT with MINA SSHD and JSecurity and you've got an awesome GIT setup for your developers.

### Gerrit

[Gerrit][gerrit] is the awesome code review tool that was created for the Google [Android][android] team. It allows easy collaboration among team members and the community of users where contributions can be reviewed and applied to a canonical repository with a button click. Gerrit is sweetness. You really have to check it out yourself to understand how amazingly powerful it is and why a system like GIT facilitates this. Gerrit is used in production on a daily basis by the Android team where JGIT is used in conjunction with the MINA SSHD server and it's getting massive throughput.

Gerrit is just one example of the very cool things you can do with JGIT, and so much is possible. I was chatting with Shawn Pearce today about some ideas he's had about creating a database structure that could be used with JGIT as the mirroring and transport is already done in JGIT. So I could easily edit Wiki content, or task lists offline in a local GIT repository and when I connected to the network again my local GIT repository could be synchronized with a remote instance. I think JGIT is a very viable replacement for JCR. A structure would need to be created within JGIT for documents, metadata, and indices but then you would have a truly distributed content store. The possibilities are endless.

### More to come

I'll have a few more posts about JGIT and I'll have an example Java-based CLI and server side packages. The CLI actually works now and Peter Royal helped me put together a JGIT+MINA SSHD+JSecurity setup which is going to be pretty cool. I'll also follow up with the transition that we are making to move to GIT for the [Nexus][nexus] team. We want to make sure that the release tooling all works correctly and John Smart has some initials findings that tell us it does.

[jgit]: http://code.google.com/p/egit/
[android]: http://code.google.com/android/
[gerrit]: http://code.google.com/p/gerrit/
[gerritdemo]: https://review.source.android.com/Gerrit#all,open,n,z
[nexus]: http://nexus.sonatype.org