How To Merge Unrelated Git Histories With Conflicts

I recently took over a project that was hosted on WP Engine. When I took over the project I didn’t have a git repository for it. I could have pulled from WP Engine initially – but I didn’t. I downloaded from a WP Engine backup instead and committed this to my new git repository. This was the start of my problem.

The code base was largely the same but git sees them as two separate repositories now. I continue on not knowing I’ll have a problem and work on the features and enhancements I’ve been tasked with building. I set up a staging environment and push to that with no issue. All the work gets approved on staging and its time to push to production. Now I’m aware of the problem.

The problem looks something like this

Now the problem is I can’t just do a force push. I’ve got to handle the merge somewhat elegantly.

Allow me to show you the command that ended up allow me to solve this issue and explain how it works.

I need to warn you that this is a risky maneuver so if you attempt this, please make sure you understand the consequences.

How to Do It

How to merge unrelated histories with merge conflicts in Git

  1. Start from the right branch

    • Make sure the current branch is the branch where you want to merge the feature branch to (master/main)

  2. Run the command

    • git merge feature/landing-page –allow-unrelated-histories -s recursive -X theirs

  3. Handle remaining conflicts

    • There still might be outstanding conflicts that you will need to manually resolve

What Does the Command Do?

git merge feature/landing-page --allow-unrelated-histories -s recursive -X theirs




We tell the command line we want to use git


Tells git we want to merge a different branch into the branch we are currently on


The branch we are merging in to our current branch


Stops git from cancelling the merge due to unrelated histories


Adds a signoff message to the commit – helpful since this a dangerous command to run


The default merge strategy when pulling or merging one branch but it doesn’t hurt to include it

-X theirs

The bit that says if there is a merge conflict we want to favor the branch we are merging in over the branch we are currently on


The above allowed me to

  • Merge the unrelated histories into one

  • Accept the incoming changes as the desired changes by default when there are merge conflicts (this saved from me having to correct thousands of files of code in a merge conflict resolution)

There were still some files where I had to manually review the merge conflict and make a decision but it was a total of 11 files as opposed to more than 1000 files with merge conflicts.

© Chris Mcintosh 2024