1

这是来自A Visual Git Reference的捕获，它解释了 rebase 的想法。

http://a.imageshack.us/img339/4264/screenshot20100903at102.png

我的理解如下。

  • git 正在跟踪更改，因此 169a6 和 2c33a 具有（跟踪）来自提交 a47c3 的更改。
  • 变基意味着将更改应用于 da985。结果，f7e63 具有（跟踪）从 b325c 到 e57cf 的所有更改。

问题。

  • 我的理解正确吗？
  • 如果是这样，我们如何确定 169a6 和 2c33a 中的更改可以（安全地）在提交 da985 时应用？
  • 如果没有，你能解释一下变基的作用吗？
4

1 回答 1

5

你表达你的理解的方式让我有点困惑。我认为您可能是对的，但以防万一，这就是我通常认为的方式。当你变基时，git 会接受这两个提交并尝试将它们应用于新的基数。e57cf 是应用 169a6 差异的结果——也就是说，在简单的理想情况下，git diff a46c3 169a6应该git diff da985 e57cf产生相同的输出。同样，f7e63 应该包含与 2c33a 相同的更改。如果有帮助，您可以将“rebase”视为“移植”的同义词。

现在，不一定能干净地应用这些更改。当rebase遇到补丁不适用的提交时，您会像合并一样遇到冲突，它会要求您解决它们然后运行git rebase --continue以移动它们。

希望这确实是一个合并操作是有道理的。这里有一些实现细节，但结果是 git 尽可能利用它的合并工具。虽然最终结果是移植 169a6 使其变为 e57cf，但提交 e57cf 的内容可以通过将 169a6 与 da985 合并来创建 - 知道它们具有共同的祖先 a47c3，因此可以进行三向合并。这允许 rebase 避免在您可能期望它们发生的某些时候发生冲突。

实现细节，如果您有兴趣：默认情况下，rebase 用于git-format-patch创建差异，然后使用git-am,--3way选项将其应用到“如果补丁记录了它应该记录的 blob 的身份，则返回到 3 路合并申请，我们在当地有这些 blob。” 也可以告诉 rebase 在内部使用合并策略，在这种情况下它直接调用合并策略（默认情况下是递归的）。无论哪种方式，它都比简单地转储补丁并天真地应用它更复杂。

（最后一段一半来自记忆，一半来自浏览 git-rebase 的来源，而且是深夜 - 如果有更多知识渊博的人发生，请随时纠正任何不准确或遗漏。）

于 2010-09-04T04:13:51.150 回答