Git workflow for long-open branches

Question

I’ve started working at a small (4 developers) company.

Our situation:

Before I’ve started working here, they’ve used subversion. Nobody had deep knowledge about source control. Therefore, there was never really a concept of how to work with source control. They had many problems with subversion, so I’ve moved our source to Git. Now we are working with Git. The product we are developing consists of a hell of a lot of Applications (Windows services, Web Services, Web Applications, Desktop Applications, Databases, Scripts…). (Most of them are created with Microsoft .Net Technology or C++.) Nearly every application communicates with the other applications or uses the same database (So making a change to one of the applications often means that we have to change other applications to). We are trying make as few dependencies as possible, but the most of them are impossible to avoid. We are developing these applications for different customers. Installing our Software is quite easy and fast… but our customers (and the companies running there servers) have a lot of policies (for instead they have to test every new or changed application themselves, which can take up to 1 month), which make an installation a very long process. Sadly we can’t change anything about it.

Now our problem:

Because an installation is so expensive, our customers don’t often do this (about once every three years). In these three years they want to get not only bug fixes but also totally new features. (Without changing to many other applications or databases.) But meanwhile we’ve implemented new features for other customers etc. Which means we can’t install the latest source (would require too many changes). We have to implement the features our customer has requested in the source we’ve installed 3 years ago… This ended up in a “workflow” looking like this:

      master
        |
        |
        \
        |\
        | installationCustomer1
        |        |
        |        | (implementing new features)
        |        | (delete branch after about 3 years) 
        |
        \
        |\
        | installationCustomer2
        |        |
        |        | (implementing new features)

We implement all new stuff on our muster branch. We create a new branch whenever we are installing our applications for a customer. When a customer requests new features we implement them in the branch we created after the installation. A lot of those features would be useful to other customers too. If this is the case, we have to implement the same thing in all the other branches (installation-branches and master). Usually this is done by copy-past the changes into the other branches (merging is not possible because the branches have too many differences). Installation-branches are getting deleted when no customer has this source installed any more (Typically after 3 years).

Now we are looking for a Git workflow which would allow us to implement such features only once and kind of merge them into the other branches. Do you have any tips for us?

Sorry for the long post, but I don’t know how I can describe our problem whit less test. Patato

Edit: We don’t make these “installation-branches” to have different features per customers. (Different features are controlled by parameters). All customers are getting the same source. The “installation-branches” should in theory be made as tags… but we have to make them as branches because our customers want us to implement new features into the code we’ve delivered at the time when we did the installation. We know it’s very bad what we are doing…but we don’t know how to do it elsewise.

Gauthier Gauthier · Accepted Answer · 2015-04-24T08:10:43

You are using branches as a configuration manager. I know this is tempting, but branches are meant for parallel development, feature separation, and the like.

An advice I got might have its place here, although I did not want to follow it at first: "do not create a branch that you do not plan to eventually merge". Otherwise you are going to live in a maintenance nightmare, probably one that made you write this post.

This is not always true. Depending on your development model, you might want branches such as master, develop, release, but in the end all commits are intended to be either discarded or merged to the trunk.

You seem to want to include different sets of features for different customers. Instead of keeping separate feature branches and merging sets of them for each customer release (or doing this by hand, since you wrote there were too many differences for merging), try to have a single code base, and a configurable build system.

There are a lot of options for configuration management, you could use make with flags, cmake with cmake-gui is a good option, and I am sure there are many more where you can easily include or exclude modules from the build.

Git workflow for long-open branches

1 Answers