在重新基准冲突中，怎么说“使用分支A中的文件，吹走主服务器中的文件”？

Question

我正在从github分支my-new-branch进行审查。 它缩小了（我知道，我知道）中的构建文件。 出乎意料的是，当我拉/变基时，缩小文件中出现了冲突。

我不想手动查看缩小文件中的每个更改。 我只想说“使用my-new-branch的文件，吹走master中的文件，继续重新设置基础”。

我怎样才能做到这一点？

Answer 1

首先，让我输入通常的注释：

• git pull本质上是git fetch然后是git merge或git rebase 。 通过--rebase或配置条目，它会在不通知合并的情况下进行--rebase 。 通常，我倾向于使用两个单独的命令，尽管在某些情况下，我事先确定需要常规合并或变基，但我将使用git pull 。

  这很重要，因为在合并与重新设置基础中，我们/他们的角色被交换了，因为...

• git rebase本质上是在新的临时匿名分支上执行的重复git cherry-pick操作的序列。 一旦将所有待重新提交的提交成功地挑选到新的匿名分支中，Git就会将分支标签从旧的提交链上剥离下来，并将其粘贴到新的分支上。

  这意味着当您进行基础调整时，您当前的分支是一个匿名分支，每个提交所来自的分支（Git称其为“ theirs”，例如--theirs或-X theirs的分支）实际上是您自己的分支。 Git称为“我们的”的分支（例如--ours或-X ours的分支） 将成为您的分支，但尚未！ 特别是对于第一步，匿名分支指向您要基于的提交，这是您（或git pull ）运行git fetch时引入的新提交。 换句话说，这是他们的承诺，而不是您的承诺，即使Git用--ours引用它。

• 相比之下，当您合并（ git merge ）时，Git停留在自己的分支上，-- --ours和-X ours指向您的分支，而--theirs和-X theirs分支则--theirs他们的分支。

大多数人发现我们/他们的角色互换至少有些混乱，因此，如果您感到困惑，您并不孤单。 我认为，如果您练习git cherry-pick会有所帮助，但即使那样仍然会很棘手。

现在，继续实际进行变基的实际步骤。

假设您开始使用bra分支：

$ git checkout bra

接下来，您将执行以下操作：

$ git rebase origin/master

复制您在bra上的所有提交，但这些提交尚未在origin/master ，因此它们会出现在新分支的origin/master的尖端之后，并最终标记为bra 。

最初，您有：

          E--F--G         <-- bra
         /
...--A--B--C--D           <-- origin/master

最后，您将获得：

          E--F--G         [abandoned - original bra]
         /
...--A--B--C--D           <-- origin/master
               \
                E'-F'-G'  <-- bra

改组的第一步是弄清楚哪些选择是樱桃选择。 通常，这就是“原始分支上所有不在目标上的提交”，即E ， F和G

接下来，Git以“分离的HEAD”（匿名分支）的形式检查目标分支的尖端提交commit D ，并运行git cherry-pick命令循环（或等效操作：确切地使用哪个命令取决于您在git rebase赋予的标志。 第一个樱桃签将E复制为E' 。 注意， 当前提交现在是提交D

这是我们和他们的标志出现的地方。让我们更详细地看看git cherry-pick所做的事情，因为这是您要解决冲突的地方。

优先选择首先将提交与其父级进行比较。 在这种情况下，我们选择了E ，因此我们将E与E的父提交（即提交B 。 这为我们提供了逐行更改的列表：删除这些行，添加其他一些行作为替换。 Git现在尝试针对当前提交D将此差异（作为合并）应用。 注意，从B到D也有变化，因此Git确实可以进行合并，并且具有通常的合并冲突和冲突解决方案。

假设从B到E的更改之一在README文件中如下所示：

@@ ... @@
 this is some context
-we ditched this
+and added this better line
 and kept this the same

如果B to- D没有出现类似的更改，则Git会获取此更改的一个副本。 但是，如果在B D ，我们改为：

@@ ... @@
 this is some context
-we ditched this
+to put in a superior line
 and kept this the same

Git声明了一个冲突：不确定“ superior”行是否比“ better”行好，反之亦然。

使用-X ours或-X theirs告诉git在发生冲突的情况下更喜欢哪一行。 假设您使用-X theirs ：这意味着更喜欢从B到E更改 。 这是因为“我们的”更改是从B到D更改：这是我们所在的（匿名）分支； “他们的”变化是从B到E 。

这并不意味着“获取他们的整个文件” 。 它仅意味着“接受他们的改变 ”。 假设在B D其他地方，我们也更改了一些拼写，但从未触及B E那些行。 -X theirs使用-X theirs进行B到E更改，但仅保留B到D更改 。

相反，我们可以让Git在此时停止变基，然后手动运行：

$ git checkout --theirs -- README

要么：

$ git checkout <id of commit E> -- README

这意味着“取从整个文件提交E完全，它出现在提交E ”，即，丢弃任何B -到- D的变化。

解决了冲突之后，您可以通过-X theirs自动获取“他们的”（ E的）更改，或通过git checkout --theirs手动获取“他们的”（ E的）文件git checkout --theirs ，并手动继续进行采摘式变基过程：

$ git rebase --continue

-Git使用解析的README进行新的提交E' ，并通过执行E与F差异并将其应用于E'进行选择F提交。

根据我们提交到提交E' ，这可能会很干净地应用，或者可能会出现更多的合并冲突。 如果出现更多合并冲突，Git会按照我们的指示处理它们，就像以前一样。

最后，Git樱桃小贴士通过从F到G求差并将其应用于F'来提交G

要完成变基，Git只需将分支标签的bra从G上剥下，然后使其指向G' 。 提交E--F--G现在已被放弃（尽管它们仍在您的引用日志中，因此默认情况下将在您的存储库中至少保留30天以上）。