git - Git 变基或合并

Question

我知道，当您想将修复添加到基础分支并将其放入所有其他分支时，re-base 非常适合。但它似乎比合并复杂得多（更多冲突）。我错过了什么吗？

Answer 1

一般来说，git rebase当您在处理未发布的内容时使用它是一个很好的做法 - 您没有推送的本地内容（或者您已经推送到其他人没有拉取的地方）。rebase 会重写历史，所以如果你 rebase，人们 pull 会有问题，而 merge 不会重写历史，因此不会给其他人造成问题。

虽然 merge 将尝试使用合并策略来合并您的更改，但 rebase 只会获取您要重新设置基准的内容的 HEAD，然后尝试应用您的更改。由于它丢失了您进行更改的时间，因此它无法像合并那样有效地解决冲突。

通常 rebase 并不复杂，除非您在一个相对较小的代码库中，其中许多开发人员同时工作并相互踩踏，或者您将代码放置很长时间。

我认为这是阅读 rebase 的好资源：http ://www.jarrodspilers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html

Jarrod 很好地定义了“变基规则”：不要变基与其他开发人员共享的分支。

Answer 2

在人们认识之前，Rebase 会吓到他们。这实际上是 rebase 和 merge 之间的一个很好的总结：请注意，最终提交所指向的快照，无论是 rebase 的最后一个 rebase提交还是 merge之后的最终合并提交，都是相同的快照——只是历史不同。Rebase 会按照引入的顺序将更改从一条工作线重播到另一条线，而合并则采用端点并将它们合并在一起。

Answer 3

从正确性的角度来看，唯一有效的答案是使用merge：如果您将提交重新设置为其他提交，则您正在创建一个在开发过程中从未存在过的状态的新提交。一种可能未经测试的状态，甚至可能无法编译，或者以其他方式荒谬。

一个例子：你分支并开发了一些调用函数的代码foo()。第二天，另一位开发人员告诉您，这foo()有一些问题，因此他目前正在删除它。因此，您使用另一个提交删除您的调用foo()，并继续完成您的功能。如果您现在将您的工作重新定位到已foo()被同行删除的 master 上，那么您的早期提交都不会编译，即使rebase操作可能不会遇到任何冲突。

这个例子只是说明了一个事实，即任何重新定位的历史都是在撒谎：它并没有真实地告诉你发展的历史，而是用发展是一个线性过程的错觉来欺骗你。这些谎言是有后果的。git是为合并而设计的，最好以这种方式使用它。