‘git rebase’的工作机制在git中
这是来自 可视化 Git 参考 的截图，解释了 rebase 的概念。
http://a.imageshack.us/img339/4264/screenshot20100903at102.png
我的理解如下。
- git 正在跟踪更改，因此 169a6 和 2c33a 具有（跟踪）提交 a47c3 的更改。
- rebase 意味着将更改应用于 da985。因此，f7e63 拥有（跟踪）从 b325c 到 e57cf 的所有更改。
问题。
- 我的理解正确吗？
- 如果是这样，我们如何确保 169a6 和 2c33a 中的更改可以（安全地）应用到提交 da985 处？
- 如果没有，你能解释一下 rebase 的作用吗？
This is a capture from A Visual Git Reference that explains the idea of rebase.
http://a.imageshack.us/img339/4264/screenshot20100903at102.png
My understanding is as follows.
- git is tracking the changes, so 169a6 and 2c33a has (keeps track of) the changes from commit a47c3.
- the rebase means applying the changes to da985. As a result, f7e63 has (keeps track of) all the changes from b325c to e57cf.
Questions.
- Is my understanding correct?
- If so, how can we sure that the changes in 169a6 and 2c33a can be (safely) applied to at the commit da985?
- If not, could you explain what the rebase does?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你表达你的理解的方式让我有点困惑。我认为你可能是对的，但以防万一你不这么认为，这就是我通常的想法。当您变基时，git 会获取这两个提交并尝试将它们应用到新的基础上。 e57cf 是应用 169a6 diff 的结果 - 也就是说，在简单的理想情况下， git diff a46c3 169a6 和 git diff da985 e57cf 应该产生相同的输出。同样，f7e63 应包含与 2c33a 相同的更改。如果有帮助的话，您可以将“rebase”视为“移植”的同义词。
现在，这些变化不一定能被干净地应用。当 rebase 遇到补丁不适用的提交时，您会像合并一样遇到冲突，它会要求您解决它们，然后运行 git rebase --continue 来移动它们。
希望这确实是一个合并操作是有道理的。这里有一些实现细节，但结果是 git 尽可能利用它的合并功能。虽然最终结果是移植 169a6 使其成为 e57cf，但是可以通过将 169a6 与 da985 合并来创建提交 e57cf 的内容 - 知道它们有一个共同的祖先 a47c3，因此三路合并是可能的。这使得变基可以避免您可能期望发生的某些冲突。
实现细节，如果您感兴趣的话：默认情况下，rebase 使用
git-format-patch创建差异，然后使用git-am，使用--3way选项，指示它“回退”在三向合并中，如果补丁记录了它应该应用的 blob 的身份，并且我们在本地拥有这些 blob。”也可以告诉 rebase 在内部使用合并策略，在这种情况下它直接调用合并策略（默认情况下是递归的）。无论哪种方式，它都比简单地转储补丁并天真地应用它更复杂。（最后一段一半来自记忆，一半来自浏览 git-rebase 的源代码，而且已经是深夜了——如果有更懂行的人过来，请随时纠正任何不准确或遗漏的地方。）
The way you phrased your understanding confused me a bit. I think you may have it right, but just in case you don't, here's the way I generally think of it. When you rebase, git takes those two commits and attempts to apply them to the new base. e57cf is the result of applying 169a6's diff - that is, in simple ideal cases,
git diff a46c3 169a6andgit diff da985 e57cfshould produce the same output. Similarly, f7e63 should contain the same changes as 2c33a. You can think of "rebase" as a synonym for "transplant", if that helps.Now, the changes cannot necessarily be cleanly applied. When
rebaseruns into a commit whose patch doesn't apply, you'll get conflicts just like with a merge, and it'll ask you to resolve them then rungit rebase --continueto move them.Hopefully it makes sense that this is really a mergey operation. There are some implementation details here, but the upshot is that git takes advantage of its merge facilities whenever it can. Although the end result is transplanting 169a6 so that it becomes e57cf, the contents of commit e57cf can be created by doing a merge of 169a6 with da985 - with the knowledge that they have a common ancestor a47c3, so a three-way merge is possible. This allows rebases to avoid conflicts some of the time you might expect them to occur.
Implementation details, if you're interested: by default, rebase uses
git-format-patchto create the diffs and then applies them withgit-am, with the--3wayoption, directing it to "fall back on 3-way merge if the patch records the identity of blobs it is supposed to apply to and we have those blobs available locally." It's also possible to tell rebase to use merge strategies internally, in which case it directly calls the merge strategy (recursive by default). Either way, it's more sophisticated than simply dumping a patch and naively applying it.(That last paragraph is half from memory, half from skimming the source of git-rebase, and it's late at night - if someone more knowledgeable happens by, please feel free to correct any inaccuracies or omissions.)