Tag Archives: discovery

Revisiting Git

I first discovered Vincent Driessen’s branching model¬†when I was investigating Git a couple of years ago. At the time I was desperate to get away from the merge issues that we were having with Subversion and was looking into both Git, and different branching models using it. Given the steep learning curve with Git we decided not to complicate things further and to stick with our old branching model; albeit with a slight change in naming convention borrowed from Vincent.

Now I’m a little more comfortable with Git it’s time to revisit our branching strategy, and use of Git overall. I’ve looked at Vincent’s branching model again, and looked at git-flow in great depth and have concluded it’s still not for us, however, the idea of codifying the workflow, and providing git extensions to aid using the workflow appealed to me immensely.

Currently we’re doing little more than branching off master for issues, with each issue (be it a new feature, or bug fix) living in its own branch. Issues are rebased into master when they’re done. Releases are also cut from master and any patches (either to the release version in QA, or to the release version in live) are cut from the release branch, rebased into that and then rebased into master.

In order to simplify our JIRA and Fisheye/Crucible setup we also push issue branches to origin making them visible from a central point, as well as providing a backup. These branches are considered private and not used by others.

Since we have tight control over all the branches a rebase only strategy works fine for our team, although we have had some problems caused by accidental merges. The next step is to improve the workflow and the merge/rebase strategies to survive all situations, codify these steps and then script them – something I’ve already started doing.

I’m also looking at this as a potential opportunity to possibly move away from Fisheye and Crucible to Stash, potentially saving some money whilst keeping the tight JIRA integration.

Wordle your code base

As part of Kevlin Henney‘s presentation at Sync Conf he showed a technique of visualising your code using Wordle. In a nutshell you strip the comments from your code (lumping it into one giant file in the process), pop it into Wordle and see what drops out. The theory behind this process is that, once you get past the scaffolding of the programming language, the language of the domain should become apparent. The results are very interesting.

I know there’s problems with our main code base. I work on it daily and the entire team knows about the issues at a near visceral level, but finding ways to express and visualise the problems can be hard. Today I discovered I work in a domain of java.lang.String and null. Not great for an OO language. Even the language scaffolding told a story. The relative size of the import keyword to the class keyword show we’ve got a lot of dependency issues.

More surprising was the result from our newer code base. Here the language of the domain started to show through, but it coloured by the unit tests which I’d forgotten to remove. On the plus side @Test features highly, as does final. Tomorrow I’ll generate a few more Wordles without the test code and use it to spark some discussion on our new architecture in our retrospective.