git pull 和 git pull --rebase 的区别

Difference between git pull and git pull --rebase

提问by Rndm

I started using git sometime back and do not fully understand the intricacies. My basic question here is to find out the difference between a git pulland git pull --rebase, since adding the --rebaseoption does not seem to do something very different : just does a pull.

有一段时间我开始使用 git 并且不完全理解其中的复杂性。我在这里的基本问题是找出 agit pull和之间的区别git pull --rebase，因为添加--rebase选项似乎并没有做一些非常不同的事情：只是拉动。

Please help me with understanding the difference.

请帮助我理解差异。

回答by mvp

git pull= git fetch+ git mergeagainst tracking upstream branch

git pull= git fetch+git merge反对跟踪上游分支

git pull --rebase= git fetch+ git rebaseagainst tracking upstream branch

git pull --rebase= git fetch+git rebase反对跟踪上游分支

If you want to know how git mergeand git rebasediffer, read this.

如果您想知道如何git merge和git rebase不同，请阅读此内容。

回答by Mauri Lopez

Sometimes we have an upstream that rebased/rewound a branch we're depending on. This can be a big problem -- causing messy conflicts for us if we're downstream.

The magic is git pull --rebase

A normal git pull is, loosely speaking, something like this (we'll use a remote called origin and a branch called foo in all these examples):

# assume current checked out branch is "foo"
git fetch origin
git merge origin/foo

At first glance, you might think that a git pull --rebase does just this:

git fetch origin
git rebase origin/foo

But that will not help if the upstream rebase involved any "squashing" (meaning that the patch-ids of the commits changed, not just their order).

Which means git pull --rebase has to do a little bit more than that. Here's an explanation of what it does and how.

Let's say your starting point is this:

a---b---c---d---e  (origin/foo) (also your local "foo")

Time passes, and you have made some commits on top of your own "foo":

a---b---c---d---e---p---q---r (foo)

Meanwhile, in a fit of anti-social rage, the upstream maintainer has not only rebased his "foo", he even used a squash or two. His commit chain now looks like this:

a---b+c---d+e---f  (origin/foo)

A git pull at this point would result in chaos. Even a git fetch; git rebase origin/foo would not cut it, because commits "b" and "c" on one side, and commit "b+c" on the other, would conflict. (And similarly with d, e, and d+e).

What git pull --rebasedoes, in this case, is:

git fetch origin
git rebase --onto origin/foo e foo

This gives you:

有时我们有一个上游，可以重新调整/重绕我们所依赖的分支。这可能是一个大问题——如果我们在下游，会给我们带来混乱的冲突。

神奇的是 git pull --rebase

一个普通的 git pull 大致是这样的（在所有这些例子中，我们将使用一个名为 origin 的远程和一个名为 foo 的分支）：

# assume current checked out branch is "foo"
git fetch origin
git merge origin/foo

乍一看，您可能认为 git pull --rebase 就是这样做的：

git fetch origin
git rebase origin/foo

但是，如果上游 rebase 涉及任何“挤压”（意味着提交的补丁 ID 已更改，而不仅仅是它们的顺序），那将无济于事。

这意味着 git pull --rebase 必须做更多的事情。这是对它的作用和方式的解释。

假设您的起点是这样的：

a---b---c---d---e  (origin/foo) (also your local "foo")

时间过去了，您已经在自己的“foo”之上进行了一些提交：

a---b---c---d---e---p---q---r (foo)

与此同时，在反社会的愤怒中，上游维护者不仅重新定义了他的“foo”，他甚至使用了一两个壁球。他的提交链现在看起来像这样：

a---b+c---d+e---f  (origin/foo)

此时的 git pull 会导致混乱。甚至是 git fetch；git rebase origin/foo 不会削减它，因为一方面提交“b”和“c”，另一方面提交“b+c”，会发生冲突。（与 d、e 和 d+e 类似）。

是什么git pull --rebase呢，在这种情况下，就是：

git fetch origin
git rebase --onto origin/foo e foo

这给你：

 a---b+c---d+e---f---p'---q'---r' (foo)

You may still get conflicts, but they will be genuine conflicts (between p/q/r and a/b+c/d+e/f), and not conflicts caused by b/c conflicting with b+c, etc.

您可能仍然会遇到冲突，但它们将是真正的冲突（在 p/q/r 和 a/b+c/d+e/f 之间），而不是由 b/c 与 b+c 冲突等引起的冲突。

Answer taken from (and slightly modified):
http://gitolite.com/git-pull--rebase

答案取自（并稍作修改）：http:
//gitolite.com/git-pull--rebase

回答by Deqing

Suppose you have two commits in local branch:

假设您在本地分支中有两个提交：

      D---E master
     /
A---B---C---F origin/master

After "git pull", will be:

在“git pull”之后，将是：

      D--------E  
     /          \
A---B---C---F----G   master, origin/master

After "git pull --rebase", there will be no merge point G. Note that D and E become different commits:

在“git pull --rebase”之后，将没有合并点G。注意D和E变成不同的提交：

A---B---C---F---D'---E'   master, origin/master

回答by drahnr

In the very most simple case of no collisions

在最简单的没有碰撞的情况下

• with rebase: rebases your local commits ontop of remote HEAD and does notcreate a merge/merge commit
• without/normal: merges and creates a merge commit

• 使用 rebase：将您的本地提交重新绑定到远程 HEAD 之上，并且不会创建合并/合并提交
• 没有/正常：合并并创建一个合并提交

See also:

也可以看看：

man git-pull

man git-pull

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.

更准确地说， git pull 使用给定的参数运行 git fetch 并调用 git merge 将检索到的分支头合并到当前分支中。使用 --rebase，它运行 git rebase 而不是 git merge。

See also:
When should I use git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

另请参阅：
何时应该使用 git pull --rebase？
http://git-scm.com/book/en/Git-Branching-Rebasing

回答by Sagar Mody

For this is important to understand the difference between Merge and Rebase.

因为这对于理解 Merge 和 Rebase 之间的区别很重要。

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards.

变基是更改从层次结构顶部向下传递的方式，合并是它们向上流回的方式。

For details refer - http://www.derekgourlay.com/archives/428

详情请参阅 - http://www.derekgourlay.com/archives/428