git中“我们”和“他们的”的确切含义是什么？

Question

这可能听起来像一个问题的基本问题，但我已经寻找答案，我现在比以前更困惑。

当我的分支合并到其他分支时，“我们”和“他们的”在git中意味着什么？ 这两个分支都是“我们的”。

在合并冲突中，“我们”总是显示两个版本中的较高者？

“我们”是否总是指合并开始时HEAD指向的分支？如果是这样，那么为什么不使用像“当前分支”这样的明确的所有权参考，而不是使用像“我们的”这样的所有格代名词（这是因为两个分支在技术上都是我们的）在所有格代词中呢？

或者只是使用分支名称（而不是说“我们的”只是说“本地主”或这样的）？

对我来说最令人困惑的部分是如果我在特定分支的.gitattributes文件中指定。在测试分支可以说我有以下.gitattributes文件：

config.xml merge=ours 

现在我签，并指向头主然后在测试合并。由于主人是我们的，并且测试的.gitattributes没有签出，它会有效果吗？如果确实有效果，因为主人现在是“我们的”，那么会发生什么？

Answer 1

我怀疑你在这里感到困惑，因为它基本上令人困惑。更糟糕的是，当你正在进行rebase时，整个我们的/他们的东西会交换角色（变得倒退）。

最终，git merge过程中，“我们的”分支是指你归并分支为：

git checkout merge-into-ours 

和“他们”分支是指你的（单）分支合并：

git merge from-theirs 

这里“我们”和“他们”有一定道理，因为，即使“他们”可能是你的，无论如何，“他们”是不是你在是当您运行一。

虽然使用实际的分支名称可能非常酷，但在更复杂的情况下会分崩离析。例如，您可以执行以下操作：

git checkout ours 
git merge 1234567 

您正在通过原始提交ID合并的位置。更糟的是，你甚至可以做到这一点：

在这种情况下

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

有不涉及分支的名字！

我觉得这里有一点帮助，但事实上，在gitrevisions syntax，您可以通过数字指单个路径索引，一个矛盾的合并过程中

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

第1阶段是共同的祖先文件stage＃2是目标分支版本，stage＃3是您要合并的版本。

---

究其原因，“我们”和“他们”的概念是否会在rebase左右交换的是，做了一系列的樱花选秀权重订工作，到一个匿名的分支（分离的头模式）。目标分支是匿名分支，合并分支是原始分支（前分支）：所以“--ours”表示匿名分支正在建设，而“ - 他们”意味着“我们的分支正在重新分配” 。

---

对于gitattributes条目：它可能有效果：“我们的”真表示“使用阶段＃2”内。但正如你注意到的那样，它当时并不实际，所以不应该在这里产生效果......好吧，除非你在开始之前将它复制到工作树中。另外，顺便说一下，这适用于我们和他们的所有用途，但有些用于整个文件级别（合并策略为-s ours;合并冲突期间为git checkout --ours），并且有些是逐条提供的， （-s recursive合并期间的-X ours或-X theirs）。这可能无助于任何混淆。

虽然我从来没有想出一个更好的名字。并且：请参阅VonC's answer另一个问题，其中git mergetool为这些引入更多名称，称它们为“本地”和“远程”！

Answer 2

Git中的'我们的'是指具有git历史的权威/规范部分的原始工作分支。

'他们的'指的是保存作品的版本为rebased（要重播到当前分支上的更改）。

这可能会被交换到的人谁不知道，做基础重建（如git rebase）实际上是把你搁置的工作（这是他们）以重播到规范/主要历史是我们的，因为我们正在将我们的更改重新定为第三方工作。

为git-checkout文档在GIT中被进一步澄清> =每f303016 commit 2.5.1为：

--ours --theirs

当检出从索引路径，检查阶段＃2 （ '我们'）或＃3（'他们的'）没有路径。

请注意，在git rebase和git pull --rebase期间，“我们”和“他们的”可能会出现交换; --ours给出了分支版本的变更重新分配到的版本，而--theirs给出了分支的版本，该分支包含正在重新分配的工作。

这是因为rebase用于将远程历史记录视为共享规范的工作流，并将待分配的分支上的工作视为要整合的第三方工作，而您暂时承担亚历山大期间经典历史的守护者的角色。作为规范历史的守护者，您需要从远程查看历史记录，如ours（即“我们的共享规范历史记录​​”），而您在您的支行上做的事情为theirs（即“一个贡献者在其上的工作” ）。

对于git-merge它以下列方式解释：

我们

此选项强制冲突的帅哥是自动解决通过支持我们的版本干净。来自另一棵与我们不冲突的树的变化反映到合并结果。对于二进制文件，整个内容都是从我们这边拿来的。

这不应该与我们的合并策略混淆，它甚至不会查看其他树包含的东西。它丢弃了另一棵树所做的一切，宣布我们的历史包含了发生在其中的所有事情。

他们

这是我们的相反。

更进一步，在这里解释如何使用它们：

合并机制（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）。

Answer 3

• 我们：这是你现在的分支。
• 他们的：这是您的行动中使用的其他分支。

所以，如果你是在分支发布/ 2.5和您合并分支功能/新按钮进去，然后在发布找到的内容/ 2.5是什么我们指和在功能上找到的内容/新按钮就是他们的所指的内容。在合并过程中，这非常简单。

大多数人所遇到的唯一问题是发生变形的情况。如果你做了一个重新的基础而不是一个正常的合并，角色被交换了。怎么样？那么，这完全是由于重组工作的方式。想想底垫这样的工作：

1. 所有提交你做了自上次拉被移动到自己的一个分支，让我们将其命名为BranchX。
2. 您检出当前分支的头部，丢弃任何本地 更改，但以这种方式检索其他人推送给该分支的所有更改。
3. 现在BranchX的每一次提交都是按照旧到新的顺序对您当前的分支进行挑选。
4. BranchX被再次删除，因此不会出现在任何历史记录中。

当然，这并不是真的发生了什么，但对我来说这是一个很好的思维模型。如果你看2和3，你就会明白为什么这些角色已经交换了。从2开始，您当前的分支现在是来自服务器的没有任何更改的分支，因此这是我们的（您所在的分支）。您所做的更改现在位于不是您当前的分支（BranchX），因此这些更改（尽管是您所做的更改）是他们的（您的操作中使用的其他分支）。

这意味着如果你合并，并且你希望你的改变永远胜利，你会告诉git总是选择“我们的”，但是如果你改变了，并且你希望你所有的改变总是获胜，那么你告诉git总是选择“他们的”。