git - rebase 以及 rebase 推送提交是什么意思

Question

人们常说，您不应该对已经推送的提交进行 rebase 。那是什么意思？

Answer 1

要理解这一点，我们需要了解一下 git 的工作原理。 git 存储库是一个树结构，其中树的节点是提交。这是一个非常简单的存储库的示例:

它在 master 分支上有四个提交，每个提交都有一个 ID(在本例中为 a、b、c 和 d)。您会注意到 d 当前是 master 分支的最新提交(或 HEAD)。

在这里，我们有两个分支:master 和 my-branch。您可以看到 master 和 my-branch 都包含提交 a 和 b，但随后它们开始分歧:master 包含 c 和 d，而 my-branch 包含 e 和 f。与 master 相比，b 被称为 my-branch 的“merge 基础”——或者更常见的是，只是“基础”。这是有道理的:你可以看到 my-branch 是基于以前版本的 master。

假设 my-branch 已经过时了，你想用最新版本的 master 更新它。换句话说，my-branch需要包含c和d。您可以进行 merge ，但这会导致分支包含奇怪的 merge 提交，这使得审查 pull 请求变得更加困难。相反，您可以进行 rebase 。

当你 rebase 时，git 找到你的分支的基础(在本例中为 b)，找到该基础和 HEAD 之间的所有提交(在本例中为 e 和 f)，并在 HEAD 上重新播放这些提交您要重新定位的分支的分支(在本例中为 master)。 Git 实际上会创建新的提交，代表您的更改在 master 之上的样子:在图中，这些提交称为 e' 和 f'。 Git 不会删除您之前的提交:e 和 f 保持不变，如果 rebase 出现问题，您可以直接回到原来的状态。

当许多不同的人同时从事一个项目时， pull 请求可能很快就会过时。 “过时”的 pull 请求是指不再与开发主线保持同步的 pull 请求，需要在 merge 到项目之前对其进行更新。 pull 请求过时的最常见原因是由于冲突:如果两个 pull 请求都修改同一文件中的相似行，并且一个 pull 请求被 merge ，则未 merge 的 pull 请求现在将发生冲突。有时，一个 pull 请求可能会在没有冲突的情况下变得陈旧:也许代码库中不同文件的更改需要您的 pull 请求中的相应更改以符合新架构，或者分支可能是在有人不小心将失败的单元测试 merge 到主分支。无论出于何种原因，如果您的 pull 请求已过时，您需要将您的分支 rebase 到最新版本的 master 分支，然后才能 merge 。