我知道当您想要将修复程序添加到基本分支并将其放在所有其他分支中时，重新基础是有用的。但它似乎比合并更复杂（更多的冲突）。 我错过了什么吗？
答案 0 :(得分：4)
一般情况下，在处理未发布的内容时使用git rebase是一种很好的做法 - 您没有推送过的本地内容（或者您已推到其他人未从中发布的地方） ）。 Rebase会重写历史记录，因此如果您进行rebase，那么人们会有问题，而merge不会重写历史记录，因此不会给其他人带来问题。
虽然merge会尝试使用合并策略合并您的更改，但rebase只会获取您正在重新定位的HEAD，然后尝试应用您的更改。由于它失去了进行更改的时间，因此无法像合并一样有效地解决冲突。
通常rebase并不复杂，除非你在一个相对较小的代码库中，许多开发人员同时工作并踩到彼此的脚趾，或者你将代码留了很长时间。
我认为这是阅读rebase的好资源：http://www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html
Jarrod很好地定义了“rebase规则”：不要重新绑定与其他开发人员共享的分支。
答案 1 :(得分：0)
Rebase在他们了解之前就吓跑了他们。这里实际上是rebase和merge之间的一个很好的总结： 请注意，您最终提交的最终提交指向的快照，无论是最后一次重新提交 for rebase 还是最后一次合并提交 合并后 ， 是同一个快照 - 它只是不同的历史记录。 重新引用按照引入的顺序将更改从一行工作重放到另一行，而合并则使用端点并将它们合并在一起。
答案 2 :(得分：0)
从正确的角度来看，唯一有效的答案是使用merge：如果将提交重新绑定到其他提交，则表示您正在创建一个具有在开发期间从未存在的状态的新提交。一个可能未经过测试的状态，甚至可能无法编译，或以其他方式无意义。
示例：您分支并开发了一些调用函数foo()的代码。第二天，另一位开发人员告诉您，foo()有一些问题，因此他目前正在删除它。因此，您通过另一次提交删除了foo()的调用，然后继续完成您的功能。如果您现在将您的工作重新绑定到同级已删除foo()的主服务器上，则即使rebase操作可能不会遇到任何冲突，也不会编译任何早期提交。
这个例子只是说明了这样一个事实：任何重新定位的历史都在说谎：它没有如实地告诉你发展的历史，而是用一种幻想来欺骗你，即发展是一个线性过程。这些谎言会带来后果。 git专为合并而设计，最好以这种方式使用。