Gitflow with multiple master branches

Question

While this is similar to the thread Git-flow and master with multiple parallel release-branches and to What's best way to work with git on multiple master branch?, it is not quite identical... I did find this one is rather similiar: Multiple projects with same GIT master, but I want discuss my specific use case...

The company I work for is in the process establishing policies and procedures for our Git work flow. We want to use the "Gitflow" model as described in the article http://nvie.com/posts/a-successful-git-branching-model/ or https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow and is commonly referenced in many discussions on the matter.

We have a use case, however, with a requirement for which I cannot find a solution documented. What if your project is used to produce more than one final product? The master branch cannot therefore represent the "release points" as if it were one single product. It seems that perhaps alternate branches are required from the master? So multiple parallel release branches?

For instance, what if the project acts as a backbone or engine to something that can have different skins, flavours, or variations but you want to have each of the full resulting final products stored in one repository?

In my particular scenario, I have a program which runs on a Linux server, but it is also distributed as a local Windows application. In these differing versions, there are large chunks of the project which may or may not be included in one or the other releases. As an example, there are libraries on the server which do not need to be included if the repo was for the server only, but which must be included for the local distribution where they would not otherwise exist. I want to pull updates to the repo onto the server at specific release points, but omit such pieces that don't belong there.

From the master branch, would I create a "Server Release" and "Local Release" branch?

Where would the development branch (and it's features) then come off of? I don't want multiple development branches, each coming from it's own release, as the code developments are in fact 99% applicable to both of those. Do I need to merge a single dev branch into one and then the other release?

Solution

If 99% of the code is shared between the two products, you could easily share the same repository. You can have a single release/develop/master branch as long as the two products are on the same release cycle e.g., version 2.0 ships at the same time.

From the master branch, would I create a "Server Release" and "Local Release" branch?

In gitflow you actually branch releases from develop! But in the case that they are on different release cycles, there's nothing stopping you from creating a release branch per product. Then you are free to merge the release branches in to the develop and master branches when they are done on their own time. The only thing here is that you will likely need to have two different flavors of tags on the master branch so that you can see where each product is on its release cycle. Or to keep the tags in the same format, you may have two master branches (one per product), which you merge into respectively when a feature is completed for the respective product.

Comments

[mstrap]

I agree. If the code is more or less identical, have one repository and just add different deployment scripts/tools (e.g. antfiles) into this repository as well. Git-Flow should work well here.

[BuvinJ]

Thanks mvd. That helps. I am still learning about this branching model, and I was clearly led astray on Gitflow by looking at secondary sources. Looking at the primary source instead, I saw how release branches are temporary, and come off of develop. I had though release was a permanent middle man which originally came from master, and then dev came from that. As a result, my proposed solution was quite mucked up. I like the 2 master branch idea. It's similar to what I truly meant. I am conversing with the team here about this now. I'll except this answer if we implement your plan.

[mvd]

There are other models where release branches are long-lived. Work starts on develop, gets merged into master (once it's considered stable enough to test) and a release branch gets branched off master when the .0 tag is being tagged. Don't feel like you have to go with git-flow because it is popular! You have a unique situation and in the end you should choose a strategy that works best for your company.

[BuvinJ]

Interesting. We are trying to establish a standard model for all of our projects. Gitflow seems like a great starting point. This project, however, doesn't seem to fit the "standard mold", so we need to tweak it, but ideally diverge as little as possible. As you suggest, I will try not be too bound up by the popular standard though.

[CME64]

this doesn't seem right, it's better to use the same flow for sub/custom products so you will have other develop & master branches too