在过去的几天里，我一直在研究使用 Git 进行 rebase 。大多数关于 rebase 的论点都说它清理了历史并使其更加线性。如果您进行简单的 merge (例如)，您会得到一个历史，显示历史何时发生分歧以及何时重新组合在一起。据我所知， rebase 会删除所有历史记录。问题是:你为什么不希望 repo 历史反射(reflect)代码开发的所有方式，包括它在哪里以及如何分歧？
最佳答案
那不正确。顾名思义， rebase 会更改提交的基础。通常在该过程中不会丢失任何提交(除非您没有获得 merge 提交)。虽然您关于将开发过程的所有内容真正保留在历史中的论点是正确的，但这通常会导致历史困惑。
特别是当与其他人一起工作时，每个人都在自己的分支上工作，同时需要其他人的某些更改才能继续(例如，A 要求 B 实现一些东西，以便 A 可以在他自己的开发中使用该功能)，这会导致许多 merge 。例如像这样:
#--#--#--#--*-----*-----------------*---#---\ Branch B
/ / / / \
---#-----#-----#-----#-----#-----#-----#-----#-----* Branch A
在这个例子中，我们有一个分支，它暂时单独工作，但不断从原始分支中提取更改(# 是原始提交，* 是 merge )。
现在，如果我们在重新 merge 之前对分支 B 进行 rebase ，我们可以获得以下结果:
#--#--#--#--#---\ Branch B
/ \
---#---#---#---#---#---#---#---#---------------* Branch A
这表示相同的实际更改，但 B 已重新基于 A 上的某个较旧提交，因此不再需要之前在 B 上完成的所有 merge (因为这些更改已存在于该较旧提交中)。现在缺少的所有提交都是 merge ，通常不包含有关开发过程的任何信息。 (请注意，在此示例中，您还可以稍后将最后一次提交重新设置为 A，以获得一条直线，从而有效地删除对第二个分支的任何提示)
关于Git rebase 丢失了历史，那为什么要 rebase？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5250817/