Git rebase 或 merge

Question

我理解re-base适用于你想在基础分支中添加修复并将其放入所有其他分支的情况，但它似乎比合并更加复杂（有更多的冲突）。 我是否遗漏了什么？

- Chen Kinnrot

Answer 1

一般来说，在处理尚未发布的本地项目时，使用git rebase是一个好的实践 - 即您尚未推送到其他人正在拉取的位置。Rebase会重写历史记录，因此如果您使用rebase，则拉取的人将遇到问题，而合并不会重写历史记录，因此不会对其他人造成问题。

虽然合并会尝试使用合并策略来合并更改，但rebase仅会获取正在进行变基操作的HEAD，然后尝试应用您的更改。由于它会丢失更改的时间，因此它无法像合并一样有效地解决冲突。

通常，重新定位操作并不复杂，除非您在相对较小的代码库中工作并有许多开发人员同时工作或长时间离开您的代码。

我认为这是了解重新定位操作的好资源：http://www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html Jarrod很好地定义了“重新定位规则”：不要重新定位与另一个开发人员共享的分支。

- Titas

---

我最近在其他地方问过这个问题，但并没有得到令人满意的答复。为什么重新设置共享历史记录会成为一个问题？我有一种感觉，那是因为人们不太擅长重新设置，并且它让他们感到害怕，但我想听听其他原因。 - Gary Fixler

Rebase共享历史被认为是不好的，因为它违背了版本控制的目的——rebase会重写历史记录。此外，它会给其他开发人员带来重大问题，因为他们会遇到这样的情况：你发布了一些内容，第二天你又对其进行了更改，但他们只拥有你之前发布的内容。当然，如果您不使用跟踪分支并始终获取(fetch)，您可以使用完全基于rebase的工作流程，但我建议不要这样做 :) - Titas

Answer 2

从正确性的角度来看，唯一有效的答案是使用merge：如果你将一个提交变基到另一个提交上，你就创建了一个状态在开发期间从未存在过的新提交。这个状态很可能没有经过测试，甚至无法编译，或者以其他方式不合理。

例如：你分支出并开发了一些调用函数foo()的代码。第二天，另一个开发人员告诉你，由于foo()存在问题，他正在删除它。因此，你用另一个提交删除了对foo()的调用，并继续完成你的功能。如果现在你将你的工作变基到已经由你的同事删除了foo()的主分支上，即使rebase操作可能不会遇到任何冲突，你早期的提交都将无法编译。

这个例子只是说明了一个事实，即任何变基后的历史都在说谎：它没有真实地告诉你开发的历史，而是用幻觉欺骗你，让你认为开发是一个线性的过程。而这些谎言会产生后果。git是为合并而设计的，最好使用它进行合并。

- cmaster - reinstate monica

Answer 3

在了解rebase之前，它会让人感到害怕。以下是关于rebase和merge的简要总结： 请注意，您最终得到的最终提交所指向的快照，无论是重新设置提交的最后一个（对于rebase）还是合并后的最终合并提交（对于merge），都是相同的快照 - 只有历史记录不同。重新设置将更改从一个工作线路重播到另一个工作线路中引入的顺序，而合并则将端点合并在一起。

- Chunbo Hua