人们常说，您不应该对已经推送的提交进行变基。这可能意味着什么？
To understand this, we need to understand a bit about how git works. A git repository is a tree structure, where the nodes of the tree are commits. Here's an example of a very simple repository:
it has four commits on the master branch, and each commit has an ID (in this case, a, b, c, and d). You'll notice that d is currently the latest commit (or HEAD) of the master branch.
在这里，我们有两个分支：master 和 my-branch。您可以看到 master 和 my-branch 都包含提交 a 和 b，但随后它们开始出现分歧：master 包含 c 和 d，而 my-branch 包含 e 和 f。与 master 相比，b 被认为是 my-branch 的“合并基础”——或者更常见的是，只是“基础”。这是有道理的：您可以看到 my-branch 是基于 master 的早期版本。
假设 my-branch 已经过时，并且您希望使用最新版本的 master 将其更新。换句话说，my-branch 需要包含 c 和 d。您可以进行合并，但这会导致分支包含奇怪的合并提交，从而使审查拉取请求变得更加困难。相反，您可以进行变基。
当您变基时，git 会找到分支的基础（在本例中为 b），找到该基础和 HEAD 之间的所有提交（在本例中为 e 和 f），并在分支的 HEAD 上重新播放这些提交您正在重新定位（在本例中为 master）。 Git 实际上会创建新的提交来表示您的更改在 master 之上的样子：在图中，这些提交称为 e' 和 f'。 Git 不会删除您之前的提交：e 和 f 保持不变，如果 rebase 出现问题，您可以立即返回到以前的状态。
当许多不同的人同时处理一个项目时，拉取请求可能很快就会过时。 “过时的”拉取请求是指不再与开发主线保持同步的拉取请求，需要对其进行更新才能合并到项目中。拉取请求过时的最常见原因是冲突：如果两个拉取请求都修改同一文件中的相似行，并且一个拉取请求被合并，则未合并的拉取请求现在将发生冲突。有时，拉取请求可能会在没有冲突的情况下过时：也许代码库中不同文件中的更改需要拉取请求中的相应更改才能符合新架构，或者分支可能是在有人意外地将失败的单元测试合并到主分支。无论出于何种原因，如果您的拉取请求已过时，您将需要将分支重新设置为最新版本的主分支，然后才能合并。
