I am dealing with a git repository that has a lot of conflicts between development and main. Git indicates there are 1000+ commits when merging the two, while in reality it should be around 40.

I am trying to merge my release branch (branched from development into main, but there are many conflicting commits. I resolved the conflicts by creating a new branch from main and merging that branch back into release with the -s ours strategy to bypass the conflicts. Normally we do a squash merge and delete the previous branch.

(For this temp branch I did not do this, since I suspect this is the reason why there are so many conflicts in the first place. I assume git cannot correctly find a common ancestor.)

However, there are now many “redundant?” commits in the history. Approximately 1000. Basically all commits since a very old release.

Our workflow is as follows:

• Create a feature/* branch for a new feature
• Merge in development if done (Always using –squash, no specific reason)
• At some point create a release/* branch from development
• Merge release/* into both main and development (Currently using –squash, reasons indicated above)

I cannot guarantee this has been done correctly in the past, but indicate this here since this might be part of the problem.

I want, and expected (perhaps naively):

• No merge conflicts between release/* and main

What is the best way to proceed so that I can merge release into main without introducing a huge number of unnecessary commits and keeping the history clean and, more importantly, make sure we do actually solve this issue.