我开始使用 git 的某个时候，并没有完全理解其中的复杂性。我在这里的基本问题是找出git pull和git pull --rebase之间的区别，因为添加--rebase选项似乎并没有做一些非常不同的事情：只是做一个拉动。
请帮助我了解差异。
git pull = git fetch + git merge 反对跟踪上游分支
git pull --rebase = git fetch + git rebase 针对跟踪上游分支
如果您想知道git merge和git rebase有何不同，请阅读此内容。
有时我们有一个上游来重新定位/倒带我们依赖的分支。这可能是一个大问题——如果我们在下游，就会给我们带来混乱的冲突。
魔力
git pull --rebase粗略地说，正常的 git 拉取是这样的（在所有这些示例中，我们将使用一个名为 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但是，如果上游变基涉及任何"挤压"（这意味着提交的补丁 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 拉取会导致混乱。即使是 git 获取;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
在最简单的无碰撞情况下
- 使用变基：将您的本地提交重定基址在远程 HEAD 之上，并且不会创建合并/合并提交
- 无/正常：合并并创建合并提交
另请参阅：
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
因为了解合并和变基之间的区别很重要。
变基是更改应如何从层次结构顶部向下传递 合并是它们向上流动的方式。
有关详细信息，请参阅 - http://www.derekgourlay.com/archives/428