1

I struggled to formulate the question in a way it does not become too subjective. Any editions are very welcome.

We have a repository where we test new features in different branches before merging them to master. It happened that master is currently being used by several clients. During one of the presentations to a new client, the sales rep offered a feature that was still in beta testing and was decisive to get the contract closed.

Our solution was to deploy that branch to another domain to let them play with it. They loved it, but none of the other clients wanted to use it. It was a core feature, so we were not able to just merge on master and enable or disable it on request.

Time passed and this new branch received more and more updates and features, up to the point that now it is a different application barely related with master (sure, they share 90% of their core, but now they serve different purposes).

This is not a technic question, project splitting has been discussed and solved before: Creating a new project out of a branch and is clear to us.

What we want to know is if you have had a situation like this and how you have solved? Did you just kept the branches as they were or did you split the repo in two?

tl;dr

We are currently divided. It makes sense to split the repository and to keep it as it is. If we split, maybe we are forced to update twice certain characteristics that are in common, but that still happens if they are in the same repo. On the other hand, having two HEADS (two repos) will make it clearer and cleaner to debug/deploy as time goes on and commits start to accumulate.

I made a diagram to illustrate our point, hope it helps: diagram

Mike
  • 35
  • 7

1 Answers1

0

As soon as you have a codebase (here a branch) which evolves to a point it needs its own lifecycle, (own set of tags, branches, release cycle), it needs to be isolated in its own repository.

That will make tagging and branching simpler: you won't have to manage two different sets of tag/branch depending on your (now) two different product.

Ideally, the second repo could reference the first repo as a submodule, if you want to keep a tight link between the two, and only make evolution to your feature.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you, @VonC. We finally decided to split them to allow the use of their own tags and release cycle, as you mentioned. Plus, it is easier now to manage two canvas boards and just reference the other in the shared issues. – Mike Oct 23 '18 at 17:21