Two mostly same codebase , how can i merge them appropiately?
First of all, this topic is not about version control systems. We use version controlling :) but it is off-topic for now.
We had kind of a medium project written in Java. Later, we need something pretty much identical but in JavaFX platform. So instead of writing from scratch, we used our previously codebase and changed necessary parts to make it run on JavaFX. It wasn't a simple task, i dont suggest it if it is not the only way.... But it is done anyway.
My problem is, now we have two seperate code-bases that are %80 - %90 identical, and both are in active development. So when we add a new feature/bugfix to one, another needs to be fixed.
How can i refactor those projects that identical parts can be managed from one place. And also i need to loosely couple identical - different parts.
I would start by splitting the code into three separate modules (e.g. one module per project):
- JavaFX user interface
- Java user interface
- Application libraries
The two user interfaces should already be separate development streams.
The application libraries will have been developed independently from the same code base. I would start from whichever version is the more advanced of the two, and then go through the version control logs and diffs for the other version, and merge the changes across. There might be some tools that can help you with this, but merging is mostly a manual process.
Where you have two incompatible requirements, you will need to "encapsulate the concept that varies" by introducing an Adapter or polymorphic implementations of the same interface. There are various techniques to help you to decouple components; e.g. the Dependency Inversion Principle, the Mediator pattern.
If you have unit tests for your application libraries, the merging process will be a lot easier.
Although it sounds like a lot of work, maintaining diverging code bases is a nightmare. Once the pattern is established it gets harder and harder to do anything about, and the precedent is in place for the next copy. Every time I have seen this pattern in practice, the product has failed slowly and expensively.