I am helping with integration of a long-running project back into the mainline. One of the feature branches that wants to come back is itself an octopus merge of (not a single octopus merge, but several merges over time) many other "mini-feature" branches.
Each of these mini-feature branches has, interspersed amongst its unique content, a common set of commits that got cherry-picked into each respective mini-feature branch. I want to clean up all these common commits before merging back into the mainline.
What might be relevant is that the feature branch's current state is "correct", i.e., the way the code looks is what it's supposed to look like.
Options I've tried:
- straight-up
rebase -i
: led to a lot of conflict, likely from cherry-picks having been applied to multiple mini-feature branches and been resolved rebase -i -p
: this results in exactly the same branch structure with common commits duplicated
Under normal circumstances, I would simply wave the white flag of surrender and do a squash-merge. However, what I need to do is replace these common commits with a new and improved set of common commits--which suggests that a rebase is the most appropriate way to proceed.
What would be ideal is to use rebase -i
with a conflict-resolution strategy that tries to resolve the conflict by selecting the conflict choice that makes the result look most like the end goal (the current octopus feature branch). But I don't know how to tell git to do that.
My questions:
- Is there some way I can tell git to resolve conflicts in the way described above?
- Is there a better, cleaner way to achieve my goal?
- Am I resigned to reconstructing these mini-feature branches by hand using rebase?