Nikolay Sturm's Blog

Musings about Development and Operations

Feature Branches and Friends

| Comments

Last month I started a new job as web applications engineer, meaning I am finally getting into programming and web operations. I am learning a lot and trying out new stuff virtually every day. This gives me the opportunity to actually experience lots of situations I had formerly only read about.

One of the first questions that came up was branching. We use git for version control of our source code, so branches are cheap and easy to use. Having played with Continuous Integration before however, I am aware that feature branches are disliked in the CI community. So when do branches make sense?

Let me start with a little background. We are a small distributed team, so pair programming is currently unfeasible. In order to maintain high quality standards (and as I am new to the team), my code is being reviewed before going live.

In order to encapsulate my work, I use private feature branches. These only exist on my local checkout and facilitate code reviews. While waiting for review, they give me the opportunity to add a quick bug fix or start working on a new feature in a separate branch. I see counter-arguments to feature branches as mostly concerning themselves with bigger teams, where conflict happens more easily.

When developing a new feature, I also use spike branches. These are private branches to quickly test an idea without any quality concerns. Once I see a sensible solution to my problem, I throw away the spike branch and reimplement the solution test-driven in my feature branch.

As we don’t have releases but deploy HEAD directly, we don’t use public release branches.