Gitflow with multiple master branches
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?
Answer
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.