How to reduce the chances of getting merge conflicts occurring in two projects of same cloned codebase

Question

I have two applications A and B.

Application A was written before application B, actually B was initially the same fork of A thus, each of the application had the same modules and same code in it.

The structure of updating the codebase of both the project has been in such a way that: updating the codebase of A will do the auto merge in the codebase of B.

But due to some specific requirements, one of the modules of B needs to be different from that module in A. So people can also directly change the codebase in B.

Also, because of some urgent requirements for B people have made changes in the codebase of B directly. So over time, this has created few differences in the almost all the modules in the project.

This is now resulting in lots of merge conflicts occurring while doing the auto merge process, i.e. when a user updated the codebase of A then in the process of the auto merge, the merge conflicts occur because of current differences present in it.

To solve this issue, I have created a static class which contains the product details, and we use that static class to do some application specific changes. Eg:

public static class ApplicationDetails
{
 public boolean isApplicationA(){ /*.....*/ }
 /*.... other details.... */
}

Now, if we have some application specific changes we use this ApplicationDetails class.

But, the codebase is now grown big and one module of it has lots of classes and logic in it. Doing this for both the projects seems a lot of tasks and very much time-consuming.

What approach should I use to solve this problem? Dividing the codebase completely (i.e. removing automerge) is not an option because there are still alot of common modules.

• Marco: Why don't you use those modules from codebase 'A' as a dependency for codebase B instead of modules? This way you do not need the auto merge and you have the sources in only 1 codebase..

Answer 1

I think to be able for auto merging again to work you would have to:

1. change the code
2. change the process

Change the code

For things that must be different in application B you should create subclasses and override the necessary functions (or separate class that implements the same interface). Keep changes as small as possible and try put them in separate protected functions if possible.

Now use your IOC container configuraiton to wire up these different classes.

basically you end up with:

• Some separate files for application B being subclasses of application A classes or interfaces
• 1 Wire up/configuration file for the IOC container to use these different classes. (have to separate files for both apps would result in no merge conflicts but you might have to add the changes in config from a manually to b)

Change the process

now if you want to change something in Application B, you are no longer allowed to touch classes of Application A, but rather you have to file and RFC (request for change) in application A and then merge that into application B. And then write your sub-classes in application B