How do I break down a large merge with conflicts into more manageable chunks?
I maintain a large git repository with 50,000 files in it. The mainline development branch is called “develop”. I have a branch called “feature” that has been worked on almost independently for 5 months. It hasn’t been possible to merge from “develop” due to the complexity of the work which but now it is near completion it wants to resync with “develop”.
Typically that means doing commit merge from “origin/develop” into “feature”, fixing the conflicts, testing, committing, and pushing. but there are a very large number of conflicts in this merge point. I count ~4000 merged changes and ~450 unmerged changes. Some of these conflicts are trivial enough (e.g. .gitignore files and so forth) but many are substantial rewrites and hard to resolve
- Is there anything like branch/jump table in Java?
- Is there a JGit plumbing API?
- How to import a GitHub hosted project as a Java Project in Eclipse?
- how to compile code from svn into jar file?
- git ignore doesn't ignore already submitted files?
- How do I create a github release on every commit?
In addition these conflicts cross over various software domains. Developers from each domain will have to resolve conflicts in their own areas. It’s going to take several days at least of concerted effort to remove the conflicts and commit it.
Is there a way I can break this down so domain owners can merge their own conflicts in parallel while preserving the commit merge point? Is there such a thing as a partial commit merge where I commit the merged stuff and not the unmerged?
My main other thought is that “feature” could merge from some intermediate tags within “develop”, e.g. we have release tags “a”, “b”, “c”, “d” during the last 5 months. So if they merge up to “a” and then “b” and so on, each merge will be less complex, however there might be more conflicts over all.
Are there any other things I could try?
One Solution collect form web for “How do I break down a large merge with conflicts into more manageable chunks?”
Your idea of merging to intermediate tags is probably the best you can achieve. You may get as many (or more) conflicts, but for the most part they should be smaller, and hence easier to merge.
However … if the problem is that you have massive conflicts caused by wholesale rewrites, there is little chance of a easy conflict resolution. Even doing the merges one commit at a time (e.g. the
git imerge approach) cannot deal with massive rewrites.