最终，在 git期间合并，我们的分支引用你要合并的到的分支：

  git checkout merge-into-ours 
 

和theirs分支指向（单个）分支：

  git从它们合并
 

在这里我们的和他们的是有道理的，因为即使他们可能是你的，他们并不是你所拥有的当你运行 git merge 。

时， 非常酷，它在更复杂的情况下分崩离析。例如，您可以这样做：

  git checkout我们的
 git合并1234567 
 

您正在通过原始提交ID进行合并。更糟的是，你甚至可以这样做：

  git checkout 7777777＃detach HEAD 
 git merge 1234567＃做一个测试合并
 

在这种情况下，不存在涉及分支名称的 ！

我觉得这里没什么帮助，但实际上，在 gitrevisions 语法，您可以在冲突的合并期间通过数字引用索引中的单个路径

  git show：1：README 
 git show：2：README 
 git show：3：README 
 

第1阶段是文件的共同祖先，第2阶段是目标分支版本，第3阶段是

---

rebase 是通过做一系列樱桃选择，转化为匿名分支（分离的HEAD模式）。目标分支是匿名分支，合并分支是原始分支（前分支）：所以--ours表示匿名分支正在建设，而 - 他们意味着我们的分支正在重新分配 。

---

至于gitattributes条目：它可以有效果：我们的真的意思是内部使用第二阶段。但是正如你注意到的那样，它实际上并不在当时，所以它不应该在这里产生效果......好吧，除非你在开始之前将它复制到工作树中。

另外，顺便说一句，这适用于我们和他们的所有用途，但有些用于整个文件级别（ -s我们$ c合并策略中的$ c>;合并冲突期间的 git checkout --ours ），其中一些是逐块的（ - 在 -s递归合并期间，我们的或 -X他们。这可能无助于任何混淆。

尽管如此，我从来没有想出更好的名字。并且：请参阅 VonC的回答以解决其他问题，其中 git mergetool 为它们引入了更多的名字，称它们为local和remote！

This might sound like too basic of a question, but I have searched for answers and I am more confused now than before.

What does "ours" and "theirs" mean in git when merging my branch into my other branch? Both branches are "ours".

In a merge conflict is "ours" always the upper of the two versions displayed?

Does "ours" always refer to the branch that HEAD was pointing to when the merge began? If so then why not use a clear possessive reference like "current branch's" instead of using a possessive pronoun like "ours" that is referentially ambiguous (since both branches are technically ours)?

Or just use the branch name (instead of saying "ours" just say "local master's" or such)?

The most confusing part to me is if I specify in a specific branch's .gitattributes file. Lets say in test branch I have the following .gitattributes file:

config.xml merge=ours

Now I checkout and point HEAD to master then merge in test. Since master is ours, and test's .gitattributes is not checked out, will it even have an effect? If it does have an effect, since master is now "ours", then what will happen?

I suspect you're confused here because it's fundamentally confusing. To make things worse, the whole ours/theirs stuff switches roles (becomes backwards) when you are doing a rebase.

Ultimately, during a git merge, the "ours" branch refers to the branch you're merging into:

git checkout merge-into-ours

and the "theirs" branch refers to the (single) branch you're merging:

git merge from-theirs

and here "ours" and "theirs" makes some sense, as even though "theirs" is probably yours anyway, "theirs" is not the one you were on when you ran git merge.

While using the actual branch name might be pretty cool, it falls apart in more complex cases. For instance, instead of the above, you might do:

git checkout ours
git merge 1234567

where you're merging by raw commit-ID. Worse, you can even do this:

git checkout 7777777    # detach HEAD
git merge 1234567       # do a test merge

in which case there are no branch names involved!

I think it's little help here, but in fact, in gitrevisions syntax, you can refer to an individual path in the index by number, during a conflicted merge

git show :1:README
git show :2:README
git show :3:README

Stage #1 is the common ancestor of the files, stage #2 is the target-branch version, and stage #3 is the version you are merging from.

---

The reason the "ours" and "theirs" notions get swapped around during rebase is that rebase works by doing a series of cherry-picks, into an anonymous branch (detached HEAD mode). The target branch is the anonymous branch, and the merge-from branch is your original (pre-rebase) branch: so "--ours" means the anonymous one rebase is building while "--theirs" means "our branch being rebased".

---

As for the gitattributes entry: it could have an effect: "ours" really means "use stage #2" internally. But as you note, it's not actually in place at the time, so it should not have an effect here ... well, not unless you copy it into the work tree before you start.

Also, by the way, this applies to all uses of ours and theirs, but some are on a whole file level (-s ours for a merge strategy; git checkout --ours during a merge conflict) and some are on a piece-by-piece basis (-X ours or -X theirs during a -s recursive merge). Which probably does not help with any of the confusion.

I've never come up with a better name for these, though. And: see VonC's answer to another question, where git mergetool introduces yet more names for these, calling them "local" and "remote"!