Question

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

请帮助我理解差异。

Answer 1

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

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

如果您想知道git merge和git rebase的不同之处，read this。

Answer 2

有时候我们有一个上游来重新设置/重绕我们依赖的分支。这可能是一个大问题 - 如果我们在下游，会给我们造成混乱的冲突。

魔术是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)

你可能仍会遇到冲突，但它们将是真正的冲突（p / q / r和a / b + c / d + e / f之间），而不是b / c与b + c冲突造成的冲突，等

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

Answer 3

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

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

＆＃34; git pull＆＃34;，将是：

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

在＆＃34; git pull --rebase＆＃34;之后，将没有合并点G.注意D和E变为不同的提交：

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

Answer 4

在最简单的无碰撞情况下

使用rebase：在远程HEAD上重新设置本地提交并且不创建合并/合并提交
without / normal：合并并创建合并提交

另见：

man git-pull

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

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

Answer 5

对于理解Merge和Rebase之间的区别非常重要。

Rebases是更改应从层次结构顶部向下传递的方式合并是他们向上流动的方式。

有关详细信息，请参阅 - http://www.derekgourlay.com/archives/428

git pull和git pull --rebase之间的区别

5 个答案: