Why would one use “git merge -s ours”?

Question

I understand that the \"ours\" merge strategy (hear the quotes around merge?) actually does not use any commits from the other branch.

The \"ours\" strategy is

Answer 1

One use is to "skip" a commit made on a maintenance branch that isn't intended to go back into your main/trunk branch of development. See this previous question for an example: git - skipping specific commits when merging

Answer 2

Another reason is when you have a branch that is very out of sync with your active branch, and you wish to update the old one with the active one, but possible merge conflicts prevent this from being done easily with a normal merge.

For example, my use case was:

You have a master and dev branch, and for some reason, you have not updated your master branch in weeks, and your attempting to merge your dev branch into master now results in merge conflicts. What you may want to do is overwrite your master branch with the current state of your dev branch, so bring them both in sync.

What you can do in this case is as follows, using steps which have outlined by another SO user in another SO answer here. But please see my warning note below.

git checkout dev
git merge -s ours master
git checkout master
git merge dev

Worth a quick note: At the end of it, my master was up to date with my dev, but dev showed 4 commits to be pushed to the remote, which is strange. There should be 0 to push, as I just wanted to update master. Nevertheless, the code seemed fine. Just worth noting, as I had never used git merge -s ours myself before this so im not 100% on its usage.

I also found another answer using ours which could be useful to people: https://stackoverflow.com/a/13307342/339803

Answer 3

One use for this is as a preparation for another merge.

Lets say you have some downstream changes that you want to merge with a new upstream version, but the new upstream version is not a git descendent of the old upstream version (maybe because the old upstream version was a stable branch that had diverged from trunk, maybe because the upstream versions were actually the results of an import tool).

What you can do is.

1. Check out the new upstream version.
2. "psuedomerge" the old upstream version.
3. Merge the new downstream version.

In this way your local changes will be merged, but git will not try to merge the old upstream changes because it considers them to be already merged.

Answer 4

Another use is as an alternative to a force-push that doesn't cause non-fast-forward changes for others.

E.g. you want to revert an incoming (stupid) commit, but you don't want to do git push -f because then you'll spend the next half-hour guiding your client through recovering from that, and you want a shorter alternative to

git checkout -b temp remote/origin
git revert HEAD
git push temp:origin
git checkout master
git merge origin/master

so you simply do

git merge -s ours origin/master

Answer 5

I'm using this pseudo-merge in an additional branch used to track the other branches, including abandoned ones. This additional branch has in fact only one file (called branches-list), which contains a text list of the active and inactive branches, but at the important points (mostly branch-points and "end-of-branch", either merge or abandon) the development branches are merged (with "-s ours") to this branch.

Here a recent screenshot of our project:

Thus, I lastly branched elo-test from master, and then from this I branched stroke-transform-example for my question here (and the answer - this should have been two different commits, though). At each such branch-point, and more importantly, at each point when a branch ends without it being merged to some other branch (which will happen to stroke-transform-example when I next clean up), I now merge this branch with -s ours to the meta-branch branches.

Then I can later delete the not-used-anymore branches without losing their history, so the output of git branch -a is always quite small. If I then ever want to look back at what I did then, I can easily find them.

(I think this is not really what this option is made for, but it works quite nice.)

Answer 6

In short: common ancestor.

Detail

Whenever you do a merge, git will find a common ancestor of the current branch and the branch to be merged. Then git merges commits after the common ancestor from the other branch into current branch.

git merge -s ours ignores any content from the other branch entirely. It's just creating a new common ancestor.

It changes the commit range to be merged for the future merges.

Here's a use case in the "Advanced Merging" chapter from the book Pro Git

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.

In this example, git merge -s ours is used to skip commits related to bugfix commits merged in release branch.