问“git rebase”和“git拉”是如何协同工作的？

EN

Rebase不会放弃某些提交，除非您执行交互式重基并显式删除某些提交。相反，使用重基策略执行git pull则相反；它保留本地分支中的所有提交，同时使用来自远程分支的更改进行更新。

一幅画在这里胜过千言万语。下面是一个图表，显示了一个本地分支会是什么样子，在一个git拉动之前和之后，通过重新基地。

remote: ... A -- B -- C
             \
local:        D -- E

遗憾的是，最近的祖先是A，因此您的本地分支和远程分支已经分别提交了2次。如果要运行git status，则Git会告诉您，您的分支落后于2提交，比远程提交早2提交。现在通过重基拉出：

git pull --rebase origin your_branch

拉完后，图表如下：

remote: ... A -- B -- C
                       \
local:                  D' -- E'

请注意，您的本地分支上的前两个提交仍然是按该顺序排列的D和E。但是现在您的工作位于分支的远程版本之上。这就是为什么这个命令被称为“because”，因为它在拉动时给分支一个新的基础。

做拉通过重新基地站在并置做一个正常的git pull通过合并。如果将远程分支合并到本地分支中，您将得到以下结果：

remote: ... A -- B -- C
             \         \
local:        D -- E -- M

现在，远程提交B和C并不直接出现在本地分支的历史记录中。相反，您将得到一个合并提交(上图中的M)。换句话说，通过合并拉出倾向于巩固提交，而重基则倾向于预测历史。

长话短说，git rebase (由其他人)和git pull (由您)可能不是您想要做的事情，通常考虑不要在共享分支上重新建立基础，除非您确定自己在做什么。

假设您正在处理的分支不是主程序(永远不要重新基于主模块)，它仍然是一个共享的分支。通常，重基重写提交的历史/SHA，如果有人重写历史记录，则需要 force push，而强制推到私有分支(例如您自己的分支)是常见的，而公共分支则不是这样。

如果您想坚持在共享分支上使用重基策略，常见的策略是使用git pull --rebase或git rebase origin/<local_branch> # instead of origin/master，这样的话，重基不再重写历史，因此使用起来很安全，尽管它感觉有点偏离了设计的目的。