时间戳

首页 > 解决方案 > `git pull --rebase` 与 `git reset --soft origin/b` 有何不同

git - `git pull --rebase` 与 `git reset --soft origin/b` 有何不同

问题描述

我试图理解git pull --rebase......为了做到这一点，该命令与：

git fetch origin
git reset --soft remotes/origin/foo
git add .
git commit -am "bar"
git merge remotes/origin/foo

与git pull --rebase上述命令相同还是不同？当然是不那么冗长，显然。

标签： gitgit-rebasegit-reset

解决方案

不，它们完全不同。

假设您master使用干净的树签出，您建议的命令集将具有指向master单个提交的效果，该提交的父级是上游提取的，但其内容具有用您的 pre- 副本替换新上游树的效果fetch master，而不合并任何上游更改。（特别是，finalgit merge remotes/origin/foo总是会说“Already up-to-date。”并且永远不会做任何更改。）

那是因为命令：

git reset --soft remotes/origin/foo

设置master为指向remotes/origin/foo而不更改当前工作目录（或索引）。然后，命令：

git commit -am "bar"

从您当前的 master 中检查（未更改的）树的单个提交。就 Git 而言，您刚刚获取了上游，然后有条不紊地master根据早期的上游将其更改为与您自己的完全一样，撤消自上次拉取以来所做的任何更改，然后将其签入上游. 由于这个提交现在是上游的后代，它已经被认为是合并的，并且：

git merge remotes/origin/foo

不会有任何影响。

相反，git pull --rebase相当于

git fetch origin
git rebase remotes/origin/foo  # or wherever you pull from

这具有重放自您上次从上游拉到上游分支顶部并指向结果以来所做的提交序列的效果。mastermaster

因此，它与上述命令的不同之处在于它向上游添加了一系列提交而不是添加单个提交，并且它在上游，而不是用旧内容替换上游并消除上游更改。最后，仍然是的后代，所以运行：mastermasterremotes/origin/foo

git merge remotes/origin/foo

仍然不会做任何事情，但它不必做任何事情，因为新获取的上游更改将被合并到新master分支中。

推荐阅读