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.
git merge feature/landing-page --allow-unrelated-histories -s recursive -X theirs
The above allowed me to
- Be on master (the WP Engine Branch) and merge in feature/landing-page (the approved branch with the feature changes)
- 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.