git中“我们”和“他们”的确切含义是什么？
这可能听起来像是一个基本的问题，但我已经寻找答案，我现在比以前更加困惑。
当我的分支合并到我的其他分支时，“我们的”和“他们的”是什么意思？ 两个分支都是“我们的”。
在合并冲突中，“我们”总是显示两个版本中的上层？
“我们”是否总是指合并开始时HEAD指向的分支？ 如果是这样的话，那么为什么不使用像“当前分支”这样的明确的占有性的引用，而不是使用像“我们的”这样的所有格代词模糊的所有格代名词（因为两个分支在技术上都是我们的）。
或者只是使用分支名称（而不是说“我们的”只是说“本地主”或这样的）？
对我来说最令人困惑的部分是如果我在一个特定分支的.gitattributes文件中指定。 让我们说在testing分支我有以下.gitattributes文件：
config.xml merge=ours 现在我结帐，并指向HEAD 掌握然后合并在testing 。 既然主人是我们的，而且testing的.gitattributes没有被检出，它会有效果吗？ 如果确实有效果，因为主人现在是“我们的”，那么会发生什么？
我怀疑你在这里感到困惑，因为它是根本混淆。 更糟糕的是，当你做一个rebase的时候，整个我们的/他们的东西会交换angular色（变得倒退）。
最后，在git merge期间，“我们的”分支引用了你正在合并的分支：
git checkout merge-into-ours
和“他们”分支是指你正在合并的（单）分支：
git merge from-theirs
在这里“我们的”和“他们的”是有道理的，因为即使“他们的”可能是你的，但是他们的并不是你在git merge时遇到的那个。
虽然使用实际的分支名称可能会非常酷，但在更复杂的情况下会分崩离析。 例如，而不是上述，你可能会做：
git checkout ours git merge 1234567
你正在通过原始提交ID进行合并。 更糟的是，你甚至可以这样做：
git checkout 7777777 # detach HEAD git merge 1234567 # do a test merge
在这种情况下， 不涉及分支名称！
我认为这里没什么帮助，但事实上，在gitrevisions语法中 ，可以在冲突合并期间通过数字引用索引中的单个path
git show :1:README git show :2:README git show :3:README
第一阶段是文件的共同祖先，第二阶段是目标分支版本，第三阶段是你正在合并的版本。
“我们的”和“他们的”概念在重新rebase期间交换的原因是，重新分配是通过做一系列的樱桃select，成为一个匿名分支（分离HEAD模式）。 目标分支是匿名分支，合并分支是您的原始分支（前分支）：所以“–ours”表示匿名分支正在build设，而“ – 他们”意味着“我们的分支被重新分配” 。
至于gitattributes条目：它可能有一个效果：“我们的”真的意思是“内部使用第二阶段”。 但是正如你注意到的那样，那个时候实际上并不存在，所以这里不应该有效果……好吧，除非你在开始之前把它复制到工作树中。
另外，顺便说一句，这适用于我们和他们的所有用途，但有些是在整个文件级别（ -s ours的合并策略; git checkout --ours在合并冲突期间的运行），有些是在一个块 – （ -X ours或-X theirs在-s recursive合并）。 这可能无助于任何混淆。
不过，我从来没有想出一个更好的名字。 另外，请参阅VonC对另一个问题的回答 ，其中git mergetool为这些引入了更多的名称，称它们为“本地”和“远程”！
Git中的“ 我们 ”是指具有git历史的权威/规范部分的原始工作分支。
“ 他们的 ”是指为了重新devise而保存作品的版本（要重播到当前分支的更改）。
这可能似乎交换到谁不知道做rebasing（例如git rebase ）实际上是把你的工作搁置（这是他们的 ），以重播到我们的经典/主要历史，因为我们作为第三方工作重新定位我们的变化。
git-checkout的文档在Git> = 2.5.1中按照f303016提交进一步阐明：
--ours--theirs当从索引中检出path时，请检查阶段＃2（'我们'）或＃3（'他们的'）是否有未合并的path。
请注意，在
git rebase和git pull --rebase，“我们”和“他们的”可能会出现交换;--ours给出了分支版本的改变，而--theirs的分支版本则保存了正在改版的工作。这是因为在工作stream程中使用了
rebase，这个工作stream程将远程的历史logging视为共享的规范，并且将您正在重新devise的分支上的工作作为要整合的第三方工作进行处理，并且暂时承担angular色在重build期间的经典历史的守护者。 作为规范历史的守护者，您需要从远程查看历史（即“我们共同的规范历史”），而您在自己的支行上做了theirs（即“一个贡献者在其上的工作” ）。
对于git-merge可以用下面的方式解释：
我们的
这个选项强制相互冲突的hunk通过支持我们的版本自动解决。 另一棵与我们不冲突的树的变化反映到合并结果。 对于二进制文件，整个内容都是从我们这边拿来的。
这不应该与我们的合并策略相混淆，它甚至根本不考虑其他树包含的东西。 它丢弃了另一棵树所做的一切，宣告我们的历史包含了它发生的一切。
他们的
这与我们的相反。
此外，这里解释如何使用它们：
合并机制（
git merge和git pull命令）允许使用-s选项select后端合并策略。 有些策略也可以采用自己的选项，可以通过给-X<option>parameter passing给git merge和/或git pull。
所以有时候可能会令人困惑，例如：
-
git pull origin master在哪里-Xours是我们的本地，-Xtheirs他们是他们（远程）分支 -
git pull origin master -r其中-Xours是他们（远程），--Xtheirs他们是我们的
所以第二个例子与第一个例子是相反的，因为我们将分支放在远程分支上，所以我们的出发点是远程分支，我们的更改被视为外部分支。
git merge策略类似（ -X ours和-X theirs ）。
