我已经阅读了git plain merge适合某些情况，而git rebase适合在Git中进行合并时的其他情况。
但我不知道如何通过变基来替代合并。在重新分支一个分支后，它仍然需要一个合并，这更可能是一个快速合并。据我所知，Rebase只是用来保证＆＃34;快进合并 - 它不能代替git merge。正确的吗？
答案 0 :(得分：3)
基本上它（或者，至少是使用rebase的一个原因）。它保证了快速合并。 （我还发现在重新定位时更容易解决冲突，因为反对合并，尤其是在使用git rerere时。）
答案 1 :(得分：1)
请注意，您最终提交的最终提交所指向的快照，无论是最后一个重新提交的提交用于rebase 还是最后一次合并提交合并后，是相同的快照 - 它只是不同的历史记录。重新映射按照引入的顺序重放从一行工作到另一行的更改，而合并则使用端点并将它们合并在一起。 / p>
以上是一个很好的总结！
答案 2 :(得分：0)
我想说这两件事在他们的行动中根本不同，并且实现了类似的事情。
git rebase将您的提交列表放在另一个分支的顶部。因此，按照您定义的顺序（如果使用--interactive）进行冲突解决，如果您没有完全正交，则每次提交都会产生冲突（即：提交可能不适用，因为每个提交都是单独申请）。 注意您还可以将多个提交合并为一个提交 - 所谓的压缩 - 在重新定位时。
git merge有不同的策略，它结合了多个分支。
另请参阅合并帮助，以了解您可以选择自动冲突解决策略（我将选择一些并粘贴部分摘要）：
ours：此选项可以通过支持我们的版本来强制自动解决冲突的帅哥。octopus：这可以解决超过两个头的情况，但拒绝执行需要手动解决的复杂合并。 subtree：这是一种经过修改的递归策略。合并树A和B时，如果B对应A的子树，则首先调整B以匹配A的树结构，而不是读取同一级别的树。话虽这么说，rebase只是一个选项，当没有人看到你的更改时，它会改变提交哈希值并且合并始终适用。另请注意，如果您有审核流程，则可以选择更改您的更改历史记录，以反映您在日志中的意图。
答案 3 :(得分：0)
我认为Git Bucket的这篇文章会给你答案。
首先要了解git rebase，它解决了与git merge相同的问题。这两个命令都旨在将更改从一个分支集成到另一个分支 - 它们只是以非常不同的方式进行。
合并很好，因为它是一种非破坏性的操作。现有分支机构不会以任何方式更改。这避免了变基的所有潜在缺陷（下面讨论）。
另一方面，这也意味着每次需要合并上游更改时，功能分支将具有无关的合并提交。如果master非常活跃，这可能会严重污染您的功能分支的历史记录。虽然使用高级git日志选项可以缓解这个问题，但它可能使其他开发人员难以理解项目的历史。
变基的主要好处是您可以获得更清晰的项目历史记录。首先，它消除了git merge所需的不必要的合并提交。其次，正如您在上图中所看到的，变基也会产生完美线性的项目历史记录 - 您可以在没有任何分支的情况下跟踪功能的提示一直到项目的开头。这样可以使用git log，git bisect和gitk等命令更轻松地导航项目。
但是，这个原始的提交历史有两个权衡：安全性和可追溯性。如果您不遵循重新规定的黄金法则，重写项目历史记录可能会对您的协作工作流程造成灾难性后果。并且，不太重要的是，rebase会丢失合并提交提供的上下文 - 您无法看到上游更改何时合并到功能中。