“git pull--rebase”与“git reset--soft origin”有何不同`

我试图理解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与上述命令相同还是不同？显然，它们没有那么冗长。

不，它们完全不同

假设您已使用干净的树签出master，建议的命令集将具有将master指向单个提交的效果，该提交的父级是已获取的上游，但其内容的效果是使用预获取master的副本替换新的上游树，而不合并任何上游更改。特别是，最终的git合并remotes/origin/foo总是说已经是最新的。永远不要做任何改变

这是因为命令：

git reset --soft remotes/origin/foo

git commit -am "bar"

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

git reset --soft remotes/origin/foo

git commit -am "bar"

从当前主服务器签入未更改树的单个提交。就Git而言，您只需新获取上游，然后根据先前的上游系统地将其更改为与您自己的主控完全相同，撤消自上次拉取以来所做的任何更改，然后在上游上签入它。由于此提交现在是上游的后代，因此已将其视为合并，并且：

git merge remotes/origin/foo

没有效果

相反，git pull-rebase相当于

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

这样做的效果是重播自上次从上游分支顶部的上游提取以来在master上进行的提交序列，并将master指向结果

因此，它与上述命令的不同之处在于，它向上游添加了一系列提交，而不是添加单个提交，并重放提交的内容，这意味着它尝试在上游的基础上重放在这些提交中所做的更改，而不是用master的旧内容替换上游，并消除上游更改。最后，master仍然是remotes/origin/foo的后代，因此正在运行：

git merge remotes/origin/foo

---

仍然不会执行任何操作，但它不必执行任何操作，因为新获取的上游更改将被合并到新的主分支中。

注意：以上假设至少在我键入此命令时，当前分支是主分支。git reset命令始终影响当前分支。更正确的是，git commit也基于索引内容进行提交，但是git commit-a的效果是先运行git add-all，这样索引内容就会根据工作树进行更新。这是主控的一个好地方。我编辑了答案以提及这一点。在本例中，因为重置是软的，所以索引和工作树实际上是相同的，所以git add和-git commit的标志没有做任何事情，据我所知。对，这就是为什么我说得更正确一点，并将其放在括号中，尽管我们假设它们开始时是相同的！。如果要使用混合重置，添加步骤将更改索引。git pull只是git fetch+git merge的缩写。git pull-rebase改为git fetch+git rebase。