git pull和git pull的区别–rebase
我开始使用git，并没有完全理解错综复杂的情况。 我的基本问题是找出git pull和git pull --rebase之间的git pull --rebase ，因为添加--rebase选项似乎没有什么不同，只是做了一个pull。
请帮助我了解差异。
git pull = git fetch + git merge跟踪上游分支
git pull --rebase = git fetch + git rebase跟踪上游分支
如果你想知道如何git merge和git rebase不同， 请阅读此 。
有时我们有一个上游，重新启动/倒回我们依赖的分支。 这可能是一个大问题 – 如果我们下游的话，会给我们造成混乱的冲突。
魔法就是
git pull --rebase一般情况下，git pull就是这样的（我们将在所有这些例子中使用一个远程调用的起源和一个叫做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但是，如果上游基础设施涉及任何“挤压”（意味着提交的修补标识改变，而不仅仅是他们的顺序），那将无济于事。
这意味着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 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)
你可能仍然会有冲突，但是它们将是真正的冲突（在p / q / r和a / b + c / d + e / f之间），而不是b / c与b + c冲突造成的冲突。
回答采取（并稍作修改）：
http://gitolite.com/git-pull–rebase
假设你在本地分支有两个提交：
D---E master / A---B---C---F origin/master
在“git pull”之后，将是：
D--------E / \ A---B---C---F----G master, origin/master
在“git pull –rebase”之后，将没有合并点G.请注意，D和E成为不同的提交：
A---B---C---F---D'---E' master, origin/master
在没有碰撞的最简单的情况下
- 与rebase：rebases你的本地提交ontop的远程HEAD，并不会创build合并/合并提交
- without / normal：合并并创build合并提交
也可以看看：
man git-pull
更确切地说，git pull使用给定的参数运行git fetch，并调用git merge将检索到的分支头合并到当前分支中。 使用–rebase，它运行git rebase而不是git merge。
也可以看看：
什么时候应该使用git pull –rebase？
http://git-scm.com/book/en/Git-Branching-Rebasing
对于理解Merge和Rebase之间的区别很重要。
反弹是如何从层次结构的顶部向下传递变化，合并是如何回stream向上。
