Is there a recommended Git branch strategy for two products in the same repo?

Question

My team has a Git repo for a large service that incorporated a related, but fairly unique, micro-service. We recently decided to separate out the micro-service into its own service in terms of release branches and deployments (so we can deploy the micro-service independently of the large service). The gotcha is there’s common code shared between the large service and the micro service so the decoupling isn’t complete; as a result, the proposal is to keep both services building in one solution and in one repo.

For the sake of this question, let’s assume that we can’t (or won’t) move the micro service into its own repo. Is there a recommended Git branching pattern for having two releases of different “products” in the same repo?

Note that we currently use the model of having a develop branch, so I’m concerned that with each product having its own release branch, we could have nasty merge conflicts when merging back into master and develop branches across two releases.

Answer 1

The recommended strategy is "don't do it". The cleanest way to do this with git is to have three repos:

• Project A
• Project B
• Common libraries

And then use git submodule(documentation here) to have both Project A and B sync with the common libraries (basically submodule lets you have a repo inside a repo). If you use any build or dependency management tools, like Maven, Gradle or npm, you could skip the git submodule part and use them to manage the dependency (which is even cleaner and less error-prone).

If you cannot split the repo in three, then you are going to need three separate masters with three develop branches and rebase the common master onto the two projects' masters to apply the changes. Note that it is extremely easy to break something this way (and to end up with merge conflicts), so this is going to require extreme care.

Answer 2

At a source code and Git level there isn't a need for separate branching strategy. You need to configure your build/deploy solution to be able to deploy one or both as needed. If you want to make a clean break and separate these two projects entirely then a separate branching strategy makes sense, otherwise you are adding complexity for no gain. It depends on your workflow and who is doing what work, but if the same team is going to manage both projects and they are truly related keeping them in the same branches may be a better strategy. If you really want to have two different release branches then you should probably have three; a release common branch to serve as an integration point and be the base branch for the other two branches.