Over the last couple of years I have released a bunch of libraries under Open Source licenses, usually on Google code. However the my last project, OpenPyro was a little different and was released on GitHub with Git as the Version Control System. I write this as a developer with more experience and comfort using Subversion and yet encourage you to release your open source projects on Git.
So what is Git? The one line description (from Wikipedia) is “Git is a distributed version control system, born with the fundamental mechanisms making branching and merging really easy.” A detailed description of Git is beyond this post but the Wikipedia page is a good place to start.
Releasing OpenPyro on Git was not an easy decision to make. The project represents a lot of work on my part and I am nowhere near as comfortable yet with Git as I was with SVN. I definitely did not want an unfamiliar Version Control System deter possible contributors to the project. However the fundamental philosophy of Git was what finally won me over.
The Git workflow is kind of new (at least to me). A developer working on a project begins by forking the core repository. He can commit code to his fork at his whim and needs to keep merging from the original branch to get the latest updates from there. Its up to him to merge changes from the core repository as they happen. People working on different forks merge changes from each other as they see fit (if you are working in a non-distributed environment, you can all merge off of a source of truth repo)
Forking basically allows the project to achieve velocities greater than the initiator of the project. If tomorrow I stop working on OpenPyro, there could be a fork that has developers more committed than I could be. Why should OpenPyro stall just cause the original developer may have.
As of right now OpenPyro has been forked a couple of times. The first fork was for a Haxe port and this was before OpenPyro was on GitHub so it wont show up on the network graph on Github. The second fork was by Kelvin Luck who fixed a few bugs on his branch and is adding new functionality there. However he didnt have to wait for me to commit his changes into OpenPyro head. I merged his changes into the OpenPyro head much later. And now the OpenPyro history shows his additions to the project as official commits.
The diagram below shows the state of the repository as it got branched and merged at different times.
This kind of collaboration wasnt possible with SVN, something I realized while working on LogBook. I would get patches for bugs on the project, sometimes feature updates I didn’t much care about. But it was up to me to add those in, and sometimes time pressures made me miss commiting some features forcing the developer on the other side to wait with probably changes local to his machine.
I have been on the receiving side of that as well and I am sure you have as well. How many times have you looked at an open source project that seems to fit the bill for what you are working for but comes up slightly short. What do you do then ? Do you fork it? Without commit access to the core repository that the original author is maintaining, you cannot branch the project. All you can do is export all the files and recommit them into a new repository that you control. But now you have lost the project history (plus something about this approach just smells wrong, with very little attribution on the “forked” repository to the main project).
There are other features that are great in Git. Offline commits is another great feature that I use quite a bit. A more detailed comparison against SVN can be found here
Whether this paradigm works as well within teams working together, I am not sure. At work we continue to use SVN right now and I am not sure if we plan to move off it anytime soon, But if you are a developer releasing code under open source, I strongly encourage you to try Git. In the meanwhile here are some resources that you could find useful. Linus Torvald’s talk at Google is a good place to start understanding Git philosophically.
Git Manual
GitCasts: Videos on using Git
Getting Started with Git docs on OpenPyro
Code Zen 
Nice writeup, Arpit! About the git at work thing, recently I’ve been seeing situations where git would be handy. For example when we want to work on a redesign without impacting in-flight QA efforts.
On the other side, I think git might still be a tough sell while the tooling is still a bit rough. Of course projects like GitX are making a serious dent there.
LikeLike
Don’t let the people at work stop you from starting to use git. Git can clone an SVN repository and allow you to make commits and resync those with the svn repository. This was actually how I stared using git a couple years ago. I would use it so I could take my svn code and go offline for the weekend but not loose the ability to make commits and merge code while without internet access.
Glad you are making the jump and I can think of no better place for Open Pyro than on github. Now I can finally get around to making some of those changes that let you run it in mxml 🙂
sim
LikeLike
@Mat, the tooling was one of the things that kept me on the fence for a long time. But not having it integrated into Eclipse hasnt been as bad as I was dreading 🙂
@Sim
Looking forward to the changes :), Git has been a great choice making things like that possible without me dreading too much integration work.
LikeLike
I have to agree with you completely. Thanks to OpenPyro I eventually got set up with git (I’d thought about it before but been put off by the windows tooling). I was a little unsure initially if I was meant to just clone your repository but I did and it seemed to work great. It’s a much more convenient way to contribute to an open source project than creating patches for svn.
It seems pretty easy to use (although I definitely don’t understand how to use all of the features yet – I’m just using it like an enhanced subversion) and for me the offline commits are a killer feature. I’m on the road at the moment so that has been great.
Re. windows tooling, I started out using the command line installed with msysgit and it seemed to work great. Then I found tortoise git which seems pretty full featured and easy to use… But it seems to have somehow broken my authentication to github – I can’t seem to push anymore (from the commandline either).
Re. switching from svn – I’ve heard good things about git-svn although I haven’t used it properly yet. But it seems it allows you to grab a git version of an svn repository and then commit to it locally etc then push it back to svn when you’re done…
Anyways – thanks for pushing me into the git world – it seems like a good place to be 😀
LikeLike
Hi,
Thanks for your review, I’m looking for a SCM which would support http it seems Git does but I read here:
http://www.linux-mips.org/wiki/Git
The http and rsync protocols are also supported but not recommended.
Do you know why ?
LikeLike
Also look into bzr, hg and mercurial. All distributed VCs available before GIT.
LikeLike