title: (Git Merging) When to use 'ours' strategy, 'ours' option and 'theirs' option?
body: <p>Definition of <strong>recursive</strong> merge strategy pulled from the <a href="https://git-scm.com/docs/git-merge#_merge_strategies" rel="noreferrer">git merge documentation</a>.</p>
  <blockquote>
  <p>This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.</p>
  <p>The recursive strategy can take the following options:</p>
  </blockquote>
  <p>As stated, the recursive strategy, which is the default strategy, makes use of the 3-way recursive merge algorithm (explained <a href="http://www.drdobbs.com/tools/three-way-merging-a-look-under-the-hood/240164902?pgno=1" rel="noreferrer">here</a> and on <a href="https://en.wikipedia.org/wiki/Merge_(version_control)" rel="noreferrer">Wikipedia</a>).</p>
  <p>My understanding is that conflicting hunks must be manually resolved and they are typically represented like this</p>
  <pre><code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;
  developer 1's code here
  ============
  developer 2's code here
  &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;
  </code></pre>
  <p>The <strong>ours</strong> option of the recursive merge strategy is documented as follows:</p>
  <blockquote>
  <p>This option forces conflicting hunks to be auto-resolved cleanly by favoring <em>our</em> version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.</p>
  <p>This should not be confused with the <em>ours</em> merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring <em>our</em> history contains all that happened in it.</p>
  </blockquote>
  <p>Now suppose I have the heads of two branches Y and M, with a common base ancestor B as follows</p>
  <p><a href="https://i.stack.imgur.com/9r32K.gif" rel="noreferrer"><img src="https://i.stack.imgur.com/9r32K.gif" alt="enter image description here" /></a></p>
  <p>When merging Y and M using the default recursive strategy, line 30 will become <code>Print(&quot;hello&quot;);</code> since at line 30, Y represents a change from the base ancestor and M does not. But if I were on branch M and run</p>
  <p><code>git merge -s recursive -X ours Y</code></p>
  <p>will line 30 become <code>Print(&quot;bye&quot;);</code> in the merged output?</p>
  <p>To those of you who say that this is obvious, note that the <strong>ours</strong> option states</p>
  <blockquote>
  <p>This option forces <strong>conflicting hunks</strong> to be auto-resolved cleanly by favoring <em>our</em> version.</p>
  </blockquote>
  <p>But (as I understand) there is no conflicting hunk at line 30.</p>
  <p>For completeness, I will also give the documentation of the <strong>theirs</strong> option:</p>
  <blockquote>
  <p>This is the opposite of <em>ours</em>.</p>
  </blockquote>
  <hr />
  <p>The documentation for the <strong>ours</strong> strategy is as follows:</p>
  <blockquote>
  <p>This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the <em>recursive</em> merge strategy.</p>
  </blockquote>
  <p>So returning to the example above, if I ran</p>
  <p><code>git merge -s ours Y</code></p>
  <p>on branch M, it is clear that line 30 will be <code>Print(&quot;bye&quot;);</code> in the merged output. In this case, why is there also not a <strong>theirs</strong> strategy? How can I achieve behaviour equal and opposite to the <strong>ours</strong> strategy?</p>
  <p>I'm asking because I'm working on a project where I want to regularly and completely overwrite the master branch with changes from another development branch, whenever the code on the development branch builds successfully. This way I can ensure that my development branch never drifts too far off from the master branch and also that the code on the master branch will build successfully.</p>
  <p>I have seen <a href="https://stackoverflow.com/questions/4624357/how-do-i-overwrite-rather-than-merge-a-branch-on-another-branch-in-git">this question</a> which recommends the solution</p>
  <pre><code>git checkout dev-branch
  git merge -s ours master
  </code></pre>
  <p>But Git simply outputs <code>Already up-to-date</code>, despite the fact that the two branches contain different code (and <code>dev-branch</code> is actually a few commits ahead of <code>master</code>).</p>
  <p>My current solution is to do</p>
  <p><code>git merge -s recursive -X theirs dev-branch</code></p>
  <p>I have also seen <a href="https://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours">this question</a> which recommends using the <strong>theirs</strong> option of the <strong>recursive</strong> strategy. But as the <strong>ours</strong> option of the <strong>recursive</strong> strategy is clearly different <strong>ours</strong> strategy, so too would the <strong>theirs</strong> option of the <strong>recursive</strong> strategy be different from the <strong>theirs</strong> strategy that I'm talking about.</p>