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!
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:
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
Dagger 2
. You could maintain one singular repository with all your code, then use a DI framework to dynamically load classes with required changes
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
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.
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.