from https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging
This will basically do a fake merge. It will record a new merge commit
with both branches as parents, but it will not even look at the branch
you’re merging in. It will simply record as the result of the merge
the exact code in your current branch.
$ git merge -s ours mundo
Merge made by the 'ours' strategy.
$ git diff HEAD HEAD~
You can see that there is no difference between the branch we were on
and the result of the merge.
This can often be useful to basically trick Git into thinking that a
branch is already merged when doing a merge later on. For example, say
you branched off a release branch and have done some work on it that
you will want to merge back into your master branch at some point. In
the meantime some bugfix on master needs to be backported into your
release branch. You can merge the bugfix branch into the release
branch and also merge -s ours the same branch into your master branch
(even though the fix is already there) so when you later merge the
release branch again, there are no conflicts from the bugfix.
A situation I've found to be useful if I want master to reflect the changes of a new topic branch. I've noticed that -Xtheirs doesn't merge without conflicts in some circumstances...
e.g.
$ git merge -Xtheirs topicFoo
CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.
In this case the solution I found was
$ git checkout topicFoo
from topicFoo, first merge in master using the -s ours strategy, this will create the fake commit that is just the state of topicFoo.
$ git merge -s ours master
check the created merge commit
$ git log
now checkout the master branch
$ git checkout master
merge the topic branch back but this time use the -Xtheirs recursive strategy, this will now present you with a master branch with the state of topicFoo.
$ git merge -X theirs topicFoo