How Can GitFlow Work for Multi-Product Releases?

Question

I am looking to adopt GitFlow for a multi-product repository. This repo contains multiple on-prem applications and libraries. Due to the nature of the products, releases are not frequent and we do not want to be releasing continuously, so there's currently no need for continuous deployment.

I am thinking of simply keeping a single main and a single develop branch for this purpose. Whenever we need to release any product, we will create a new release branch from develop, and execute the rest of GitFlow as-is.

Is this doable, or are there things that I am not seeing that would make traditional GitFlow difficult for a multi-product repository? For example, is it better for me to have one develop branch for each product? Or perhaps one main branch for each product?

Answer 1

If you are considering having per-product develop and master branches, then you should also seriously look at having a per-product repository. That will give a much better developer experience than per-product branches in a single repository.

That said, the main issue I see with using GitFlow in a multi-product repository is that the default assumption in GitFlow is that the top of the master branch represents the status of the code as it is currently deployed in production. That assumption does not hold in a multi-product repository where the products are not all deployed in lock-step.

This issue can be mitigated by careful naming of your release branches and your tags, essentially making those per-product. This will be very doable if it is rare to release multiple products at the same time.

• Doc Brown: +1. Let me add that a per-product repository can be problematic when you have several small products and a huge base of commonly shared libs between them. In this case a mono repo can be much more effective. But the key thing is, as this answer states correctly, careful naming for release branches / tags per product.