git pull和git pull的区别是rebase

我以前开始使用git，并没有完全理解其中的复杂性。我在这里的基本问题是找出git pull和git pull --rebase之间的区别，因为添加--rebase选项似乎没有什么不同:只是做一个拉。

请帮助我理解其中的区别。

239421 次浏览
小开

在最简单的无碰撞情况下

  • with rebase:在远程HEAD上重新创建本地提交，并执行不创建合并/合并提交
  • Without /normal:合并并创建合并提交

参见:

man git-pull

更准确地说，git pull使用给定的参数和运行git fetch 调用git merge将检索到的分支头合并到当前 分支。使用——rebase，它运行git rebase而不是git merge
< p >参见:< br > 什么时候我应该使用git拉-rebase? < br > http://git-scm.com/book/en/Git-Branching-Rebasing < / p >
小开
最佳答案

git pull = git fetch + git merge用于跟踪上游分支

git pull --rebase = git fetch + git rebase用于跟踪上游分支

如果你想知道git merge和git rebase有什么不同，读到这。

小开

有时我们有一个上游，它会重设/重绕我们所依赖的分支。这可能是一个大问题——如果我们在下游，就会导致混乱的冲突。

神奇的是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

但如果上游的基地调整涉及到任何“挤压”，这将无济于事。(这意味着提交的patch-id改变了，而不仅仅是它们的顺序)。

这意味着git pull -rebase要做的远不止这些。下面解释一下它的功能和方式。

假设你的起点是这样的:

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

随着时间的流逝，你已经在自己的“食物”上做出了一些承诺:

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

与此同时，在一阵反社会的愤怒中，上游的维护者不仅改变了他的“食物”，他甚至用了一两个南瓜。他的提交链现在看起来是这样的:

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

在这个时候猛拉会导致混乱。甚至是一个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 < / p >

小开

因此，理解Merge和Rebase之间的区别非常重要。

Rebases是指改变应该如何从层次结构的顶部向下传递 合并是指它们如何向上流动

详细信息请参考- http://www.derekgourlay.com/archives/428

小开

假设你在本地分支中有两个提交:

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

“git拉”之后，会是:

      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

提交答案