vesna-drivers git visualization

16.06.2014 17:41

Further in the context of two years in development of firmware for VESNA sensor nodes in Logatec, here's another view on the firmware. I used git-big-picture to graph the branching and merging of the source code.

We use a private GitHub repository to collaborate on the code. At the time of writing, it had 16 forks and 7 contributors to the master branch. Before that we used Subversion, but switched to git soon after I joined the team.

vesna-drivers repository branching visualization

Red are commits pointed to by tags, blue are branch heads and white are merge and bifurcation commits. Other uninteresting commits are not shown - zero or more intermediary commits are implied by graph edges. Time, or rather entropy, roughly increases from left to right.

Below is a detail from that picture. If you're curious, you can also download the complete graph as a rather large PDF (most branch names and tags have been redacted though).

vesna-drivers repository branching visualization, detail

At the first glance, this looks pretty chaotic. Definitely our academic environment is a bit less strict regarding the code structure than what you might see in a production project. That's not necessarily a bad thing. Many people here are researchers first and software developers second. For many, this has been their first encounter with source version control.

On the other hand, the whole point of this repository is that work can be shared. Pieces that have been useful in one project are often useful again in another. Searching 16 repositories and countless branches for a driver you might reuse isn't very fun. So some kind of structure is a must.

It's hard to get this balance right tough. On one hand you don't want to be too strict when accepting code to the git master, since then you have less code to share. Often it's even impossible for the reviewer to run-test the code since he might not have the hardware necessary. On the other hand, merging code that will be a maintenance hell later on is counter productive as well. There's no use trying to share code that will cost people more time to debug it than it would to rewrite it from scratch.

We're currently trying to go with a system of GitHub pull requests and a Wiki page that lists all the projects in private branches and I think setting up automated builds was worth the effort. But I guess after two years we're still trying to find the sweet spot.

Posted by Tomaž | Categories: Code

Add a new comment


(No HTML tags allowed. Separate paragraphs with a blank line.)