Pierre de LESPINAY
Pierre de LESPINAY

Reputation: 46178

Git - 2 projects sharing features

I have a project that I'd like to clone into a new project which will evolve simultaneously with the original.

Both projects will have ultimately different goals but will share future features.

If I keep a single repository with 2 branches, I'm afraid this could lead to too many differences.
If I split projects into 2 repositories, I'm not sure how easy it will be to merge features between then.

I have only been using git for the last 2 years, and I'm not sure to have mastered it.

How can I make 2 projects evolve and share some features with git ?

Upvotes: 2

Views: 147

Answers (1)

Peter Lundgren
Peter Lundgren

Reputation: 9197

This really has very little to do with Git. You would face these same organizational questions with any source control tool (including none). These questions persist because they are difficult to answer. I don't know enough about your projects to give you a recommendation, but I will offer some alternatives. These options aren't mutually exclusive.

  • Different Branches in the Same Repository - This is practically having 2 different repositories except that they clone at the same time. Merging between the 2 branches wont make any sense, so there really isn't any advantage in keeping source for both projects together like this. Don't do this.
  • One Repository; Distinguish at Build Time - Keep one repository with one master branch that contains 2 builds. You can either build project A or project B from the same source. Any features sharing source will literally build from the same files. Any time you make a change, you must make sure that both builds still work and that your change for one project did not break the other. Because you are only using one project, versioning, releasing, and branching are easier.
  • One Repository; Distinguish at Run Time - Like before, only, instead of 2 separate builds, have one build that produces a single build output. Features can be enabled and disabled at run time. You could do this via a menu, configuration file, or licensing scheme if you wan't to sell them as different products.
  • Three Repositories - You have 2 deliverables and some common code they share. Break out that common code into a separate library that you also maintain. You then have a dependency graph like so:

    +-----------+    +-----------+
    | Project A |    | Project B |
    +-----------+    +-----------+
             \          /
              \        /
          +----------------+
          | Common Library |
          +----------------+
    

Both Project A and Project B depend on the Common Library. You can manage this dependency in many ways (dependency management is a huge topic in itself). The Common Library could have a build that publishes an artifact somewhere that can be consumed by the builds for Project A and Project B later. Alternatively, you can build with the source of the library in a subdirectory of each project. Git Submodules can help with this approach.

Upvotes: 2

Related Questions