2

We have a git repository with existing code. Now we have 3 teams, those teams will start developing with the base repository. Two teams will be developing a free version and one team the paid version. But the paid version will not necessarily have all the features that the free version has (just some features).

Approach

We were thinking maybe the free version would be a fork of the current repository, and the paid version will continue working on the repository. But we need to define a mechanism to sync a fork project with the origin project. Find a mechanism to add new features from the fork.

How can we do that?? Is there a recommendation for that? or if you can suggest another approach will be awesome.

tkruse
  • 10,222
  • 7
  • 53
  • 80
r35daleney
  • 41
  • 4
  • 1
    Forking the application seems excessive. Can't you use compiler directives to build different versions of the software based on build-time parameters? – Daniel Mann Apr 12 '19 at 22:37
  • Similar question: https://stackoverflow.com/questions/15081145, https://softwareengineering.stackexchange.com/questions/60393 – tkruse Apr 14 '19 at 01:16
  • Possible duplicate of [Best way to maintain different versions of codebase for different hardware setups with GitHub](https://stackoverflow.com/questions/17328714/best-way-to-maintain-different-versions-of-codebase-for-different-hardware-setup) – tkruse Apr 14 '19 at 01:18
  • Is the free version also open-source? Also It may help if you describe what kind of software you talk about. – tkruse Apr 14 '19 at 01:20

1 Answers1

2

That approach (multiple repositories) works best for modules or micro-services, not for monolithic applications.

For the latter, a monorepo is better, with dedicated branches, and with feature flags you can activate at the compilation, to generate two different deliveries.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Do you know some git flow that allows this approach? – r35daleney Apr 14 '19 at 18:51
  • The gitworflow I mention here is quite flexible: https://stackoverflow.com/a/216228/6309. But the feature flag itself is not part of any flow, and must be set separately. – VonC Apr 14 '19 at 18:55
  • I was thinking that maybe we can have 2 develop branches each for the versions and feature branches, but It seems quite coupled – r35daleney Apr 15 '19 at 14:10
  • @waluche yet, 2 develop branches are possible (one for each team, I suppose) – VonC Apr 15 '19 at 15:04