I’m your clone!
Our list of things to do after the 3.1 release had been finalized and finished is long. On top of that list, however, is «move source code hosting from svn to git». The team has had a long discussion trying to find a good git hosting provider. We’ve been with sourceforge.net for a long time, and they even have a git source code hosting service which was available to use. However, it became glaringly obvious that the collaboration tools available to us at this time was sub-par compared to the three other options we considered:
- Staying with Springloops
Picking a git source code hosting service
Option 1 would have been the easiest. However, Springloops is a (at least has been so far) a very “closed” platform – insofar that it is very hard to share code with outsiders. Their 2.0 platform looks promising, but it is still too much targetted at closed teams and closed code to be of interest. So, staying with Springloops was out of the question.
Option 2 and 3 were the only two remaining git code hosting services considered. In the end, we picked github. Why?
- Using commit / push hooks with a hosted gitorious.org repository seemed very difficult. Although probably possible, the hook services provided with github.com were much easier to use and set up
- Github has a much better team setup than gitorious.org. While this may be a subjective opinion – we definately felt we had more power with the features available on github than on gitorious
- Merge / pull request integration appears to be more integrated, visible and easy on github.com
- Forks, branches and repository overview is much easier to get an overview of on github.com
- The “organisation” feature on github.com
This isn’t a rant on how bad gitorious.org is – we don’t think it is bad at all. However, the features available on github.com was – to us – far superior than those available on gitorious.org. In any case, we’ve chosen to go with github.com.
Migrating the source code from svn to git
There are several good tutorials available on how to migrate from svn to git. Github.com has its own, available here: http://help.github.com/import-from-subversion/. One thing that was missing from that howto, however, was a dead simple way to map our current structure (trunk, tags, branches) into a more “standard” git repository setup, with master and next branches. Again, a quick google search was all it took to find this awesome article by John Albin: http://john.albin.net/git/convert-subversion-to-git. That article mentions all steps needed to convert a classic svn repository into a classic git repository, complete with svn revision history, author logs and more. Combined with the instructions in the github.com tutorial we were up and running in almost no time (the main part of the time it took was waiting for all the 1766 revisions to be imported, one by one by freaking one).
Choosing the upcoming commit/merging/branching strategy and development strategy
Again, this was a team decision, although not a hard one. We actually ended up with a very “classic” git branching strategy, with one main stable branch (master) and one branch for the current ongoing development of the upcoming stable version (next). The next branch will see tons of feature branches, just like a regular git hosted project. Nothing magic!
In addition to this, we’ve decided to adopt a scrum-based approach to the bug genie development with regular, defined, sprints. During a sprint, we will branch out any new features from next, and as soon as it is deemed stable, it will be merged back into next. After a sprint is completed, next will be merged back into master, with (hopefully) only stable features. As soon as we’ve reached all targets set for a release, we will tag master and release. This means we may do feature branches for features not yet to be included into next or master, but the flexibility of git will hopefully let us juggle this with ease 🙂
As with any development strategy, this is up for review at any time. Expect changes 🙂
Cloning and forking
Feel free to clone, fork and send pull requests. The only thing we’re going to be very adamant about is the fact that your contribution must follow some simple guidelines:
- Your changes / additions must follow the bug genie coding standards, described here: http://thebuggenie.com/thebuggenie/wiki/TheBugGenie:Development:CodingStyle
- Changes must not break existing features / behaviour. Exceptions are of course made when improvements are made.
- Contributions you make are not limited to the current licence. This means your contributions may be relicensed in the future, should we choose a different license for The Bug Genie. No exceptions.
Noone describes successful cloning better than our dear Arnold. Take it away!