Question

我正试图了解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与以上命令相同还是不同？显然，它不那么冗长。

Answer 1

不，它们完全不同。

假设您已经用干净的树检出了master，那么您建议的命令集将具有指向master指向其父级是上游提取但其 content的单个提交的效果。 的作用是用预取master的副本替换新的上游树，而不合并任何上游更改。（特别是，最后的git merge remotes/origin/foo始终会说“已经是最新的。”，并且从不进行任何更改。）

那是因为命令：

git reset --soft remotes/origin/foo

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

git commit -am "bar"

从当前主节点检入一次提交，以查找（未更改的）树。就Git而言，您只是重新获取了上游，然后根据之前的上游有条不紊地对其进行了更改，使其看起来完全像您自己的master，撤消了自上次提取以来所做的任何更改，然后将其检入在上游。由于此提交现在是上游的后代，因此已经被认为是合并的，并且：

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是 still remotes/origin/foo的后代，因此运行：

git merge remotes/origin/foo

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

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

1 个答案: