Managing long-running branches is always a daunting task, especially when your team is large and ships features frequently, In this article, we will see how we at Lumel approach merging long-running branches.
So a little bit of context here, we have a very unique problem where we have to maintain two branches for our product called InfoRiver Matrix, btw if you're into reporting, analytics, FP & A in the PowerBI space you must definitely check it out.
Problem
we have two versions. Enterprise and Premium, all the features which are available in Premium are also available in Enterprise. there can be cases where there are enhancements to a single feature in both enterprise and premium at the same time which can cause conflicts.
As you can see when we need to release v2.4 we have to merge with main which has v2.3Premium's changes.
recently when we went without a release for more than 3 months, we had more than 100 conflicts, here comes the problem, when we have less than 20 conflicts are so, it is fairly easy for a single person to collaborate with the owners of conflicts and resolve them, but with around 100 conflicts and remote work on top of that, it wasn't a viable option for us, so we had to improvise.
Solution
we wrote a script which finds all the conflicts and who are the people responsible for them, we also assigned an owner for each file and they will have to collaborate with the other collaborators of that file.
the script outputs a CSV which we later imported to notion and tracked the status.
when someone resolves their conflict they add a temporary commit and push it to remote, and when everyone is done. we do a soft reset to the initial merge commit and create a single merge commit with all the conflict resolutions so we don't pollute the commit history.
this is how we tackled our merge conflict hell problem, do let us know in the comments if there are better solutions and your thoughts on this approach
Top comments (0)