Git中“我们”和“他们的”的确切含义是什么？
这可能听起来像是一个基本的问题，但我已经寻找答案，我现在比以前更困惑。
当我的分支合并到其他分支时，“我们”和“他们的”在git中意味着什么？ 两个分支都是“我们的”。
在合并冲突中，“我们”总是显示两个版本中的较高者？
“我们”是否总是指合并开始时HEAD指向的分支？ 如果是这样，那么为什么不使用像“当前分支”这样的明确的所有权参考，而不是使用像“我们的”这样的所有格代名词（这是因为两个分支在技术上都是我们的）在所有格代词中呢？
或者只是使用分支名称（而不是说“我们的”只是说“本地主人”或这样的）？
对我来说最令人困惑的部分是如果我在特定分支的.gitattributes文件中指定。 让我们说在测试分支我有以下.gitattributes文件：
config.xml merge=ours
现在我签和点HEAD 掌握然后在测试合并。 既然主人是我们的，并且测试的.gitattributes没有被检出，它会有效果吗？ 如果它确实有效果，因为主人现在是“我们的”，那么会发生什么？
我怀疑你在这里感到困惑，因为它基本上令人困惑。 更糟糕的是，当你正在进行rebase时，整个我们的/他们的东西会交换角色（变得倒退）。
最终，在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语法中，可以在冲突合并期间通过数字引用索引中的单个路径
git show :1:README
git show :2:README
git show :3:README
第一阶段是文件的共同祖先，第二阶段是目标分支版本，第三阶段是你正在合并的版本。
“我们的”和“他们的”概念在rebase期间被换掉的原因是rebase通过做一系列樱桃选择进入匿名分支（分离HEAD模式）。 目标分支是匿名分支，合并分支是原始分支（前分支）：所以“--ours”表示匿名分支正在建设，而“ - 他们”意味着“我们的分支正在重新分配” 。
至于gitattributes条目：它可能有一个效果：“我们的”真的意味着“在内部使用第二阶段”。 但是，正如你所注意的那样，它当时并没有到位，所以它不应该在这里产生效果......好吧，除非你在开始之前将它复制到工作树中。
另外，顺便说一句，这适用于我们和他们的所有用途，但有些是在整个文件级别上（对于合并策略来说是-s ours的; git checkout --ours合并冲突期间的行为） （在-s recursive合并期间为-X ours或-X theirs ）。 这可能无助于任何混淆。
不过，我从来没有想出一个更好的名字。 并且：请参阅VonC对另一个问题的回答，其中git mergetool为这些引入了更多名称，称它们为“本地”和“远程”！
Git中的' 我们 '是指具有git历史的权威/规范部分的原始工作分支。
' 他们的 '是指为了重新组合而保存作品的版本（要重播到当前分支上的更改）。
这似乎是交换给不知道做基准（例如git rebase ）的人实际上是在搁置你的工作（这是他们的），以便重放到我们的规范/主要历史记录上，因为我们是将我们的变化重新定为第三方工作。
根据f303016 commit， git-checkout的文档在Git> = 2.5.1中进一步阐明：
--ours --theirs
当从索引中检出路径时，请查看第2阶段（'我们的'）或第3阶段（'他们的'）的未合并路径。
请注意，在git rebase和git pull --rebase ，'我们'和'他们的'可能会出现交换; --ours给出了分支版本的变化重新分配到的版本，而--theirs的分支版本则保存了正在重新分配的作品。
这是因为在将工作流视为共享规范的历史记录的工作流中使用了rebase ，并将待分配的分支上的工作视为要整合的第三方工作，并暂时承担角色在重建期间，经典历史的守护者。 作为规范的历史的守护者，你需要从远程查看历史， ours （即“我们共同的经典历史”），而你做了什么在你身边的分支为theirs （即“一个出资人在它之上的工作” ）。
对于git-merge它以下面的方式解释：
我们的
这个选项强制相互冲突的hunk通过支持我们的版本自动解决。 来自另一棵与我们不冲突的树的变化反映到合并结果。 对于二进制文件，整个内容都是从我们这边拿来的。
这不应该与我们的合并策略相混淆，它甚至不会考虑另一棵树包含的东西。 它丢弃了另一棵树所做的一切，宣布我们的历史包含了发生在其中的所有事情。
他们的
这与我们的相反。
此外，这里解释如何使用它们：
合并机制（ git merge和git pull命令）允许使用-s选项选择后端合并策略。 有些策略也可以采用自己的选项，可以通过给-X<option>参数传递给git merge和/或git pull 。
所以有时候可能会令人困惑，例如：
git pull origin master ，其中-Xours是我们的本地人， -Xtheirs他们是他们的（远程）分支 git pull origin master -r其中-Xours是他们的（远程），- -Xtheirs他们是我们的 所以第二个例子与第一个例子相反，因为我们将分支放在远程分支上，所以我们的出发点是远程分支，并且我们的更改被视为外部分支。
类似于git merge策略（ -X ours和-X theirs ）。
我知道这个问题已经得到解答，但是这个问题使我困惑了很多次，我建立了一个小型参考网站来帮助我记住：https：//nitaym.github.io/ourstheirs/
以下是基础知识：
合并：
$ git checkout master
$ git merge feature
如果你想选择master版本的版本：
$ git checkout --ours codefile.js
如果您想选择feature的版本：
$ git checkout --theirs codefile.js
底垫：
$ git checkout feature
$ git rebase master
如果你想选择master版本的版本：
$ git checkout --ours codefile.js
如果您想选择feature的版本：
$ git checkout --theirs codefile.js
（当然这是为了完整的文件）
链接地址: http://www.djcxy.com/p/7175.html上一篇: What is the precise meaning of "ours" and "theirs" in git?