GIT : Handle multiple variations of th same sofware in a single repo

user_16586034 0
Viewed 364

My team and I are working on multiple projects at a time, but they all use the same code base, and it needs adaptations for each projects.

So for example, we have the base code, that contains components A and B. For each new project, we have to modify B, but A remains the same.

At the moment, we have one GIT repo for each project, but sometimes we discover an issue in A that we have to fix in all of our projects. So we are considering the possibility to keep all of our projects in the same repo and use branches to manage them in order to simplify the corrections for the common components.

I've been looking for workflows that cover this kind of code management (gitflow, github flow, gitlab flow...) , but I didn't find anything that matches our needs.

Is managing different variants of a codebase in the same repo a bad idea? If not, is there a workflow out there i may not have found that would suit this kind of application? Or do we just use a standard workflow and treat all project branches as single repos?

Thanks in advance for your help!

workflow git
2 Answers

Dos

Managing multiple versions of the same repo can be a good idea, this depends on the exact codebase, goal and chosen approach. Ideally you want encapsulate core functionality, so that there is a layer which is always the same and then there are high-level layers which are distinct and access the core layer.

There are endless options how you could achieve this, I'd like to briefly mention a few:

  • Using git: An option is to have the unchanging core functionality in a repository X, then dynamically import this repository in your other project's repositories. A prime example of such functionality is Git Submodules
  • Using dependency injection: Depending on the language of your project there are DI frameworks, such as Dagger 2. You could maintain one singular repository with all your code, then use a DI framework to dynamically load classes with required changes
    • An example might help: Assume there is a UI class A. This class depends on either model class B or C, depending on which variant of your application you want to build. Both B or C depend on class D which is your unchanging core functionality. In this scenario it's possible to let Dagger handle the dependency injection and provide either B or C
    • https://dagger.dev/
  • You can use dedicated build tools, such as Gradle or Maven. It's possible to define whole build pipelines, so that you keep all of your codebase in one repository and execute a specific build pipeline depending on what version you intend to build.
  • Yet another possibility is using something like Jenkins to define individual build pipelines for each respective application version. This is essentially just a variation of previously mentioned approaches, but with a more generic tool

You will likely need to refactor your codebase to utilize either of these approaches cleanly, however it is well worth it to avoid running into technical debt quickly.

Don'ts

What you do NOT want to do under any circumstances is replicating the codebase with only slight changes and put it wholecloth into distinct repositories.

I have actually seen this approach live and in action - it blows up horribly into your face. You end up maintaining multiple similar but to some degree different codebases. Very likely improvements from A don't always make it into B and vice versa due to time constraints and you end up doing the same work multiple times. It will also be hard to keep track of the state of either codebase.

user_74476600

I think the standard behavior of a branch is the means of choice. This can then be used to evolve A and serve as the basis for B.

Have you looked at the concept of tags? This is a way to assign a unique identifier to a commit. If you use this e.g. in A, you can then see in the derived branches on which basis of A your feature B is based.

user_20328640
Related