Question

我知道'git rebase'放弃了一些提交。因此，如果开发人员这样做，并将更改推送到远程仓库，那么这意味着这些提交也将从远程仓库中删除。

当另一个开发人员做'git pull'时，那些提交也会从他/她的本地回购中删除吗？

Answer 1

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

这张照片胜过千言万语。下面的图表显示了通过rebase git pull之前和之后局部分支的样子。

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

最初，最近的祖先是A，从那时起，本地和远程分支的分歧每个提交2次。如果您要运行git status，Git会告诉您，您的分支机构落后于2个提交，并且远远超过其远程对应设备。现在通过rebase进行拉动：

git pull --rebase origin your_branch

拉动后，图表如下所示：

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

请注意，您本地分支上的前两个提交仍按此顺序排列D和E。但是现在你的工作位于分支的远程版本之上。这就是命令被调用＆＃34; rebasing，＆＃34;因为它在拉动时为你的分支提供了新的基础。

通过rebase进行拉动与通过合并执行正常git pull并列。如果你将远程分支合并到你的本地分支，你最终会得到这个：

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

现在，远程提交B和C不会直接显示在本地分支的历史记录中。相反，您将在上图中留下合并提交（M）。换句话说，通过合并拉动趋向于整合提交，而变基倾向于预先确定历史。

Answer 2

很长的答案，git rebase（由其他人），然后git pull（由你）可能不是你想做的事情，通常认为不要共享分支除非您确定自己在做什么。

假设您正在处理的分支机构不是主设备（从不对主设备进行重新设定），它仍然是共享分支。通常，rebase 重写历史记录/提交的SHA，如果有人重写历史记录，则需要强制推送，同时强制推送到私有分支是常见的（比如说你自己的），公共分支的情况并非如此。

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

'git rebase'和'git pull'如何协同工作？

2 个答案: