git pull --rebase导致意外的图形 [英] git pull --rebase leads to unexpected graph

问题描述

我正在分支foo上工作.我没有暂存的更改，没有工作的更改，完全干净的状态，根据我的包装箱，其中HEAD == foo == origin/foo.

I am working on a branch, foo. I have no unstaged changes, no working changes, perfectly clean state, where HEAD == foo == origin/foo according to my box.

$ git status
# On branch foo
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   some_irrelevant_file_here

$ git log --pretty=...
* 456520c 2015-02-13 (HEAD, origin/foo, foo) Commit A
* 23bfcd1 2015-02-11 Commit B
* b0bdd18 2015-02-12 Commit C

然后要求我查看同事推动的一些更改，所以我这样做:

I am then asked to look at some changes that a colleague pushed, so I do:

$ git pull --rebase origin foo
remote: Counting objects: 47, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 36 (delta 22), reused 0 (delta 0)
Unpacking objects: 100% (36/36), done.
From ...
 * branch            foo       -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Fast-forwarded foo to 43dad88c737762e0f1e84fdcd135155080bdce2a.

此时，我的图形如下:

$ git log --pretty=...
* 43dad88 2015-02-13 (HEAD, foo) Commit D
* 40039f9 2015-02-13 Commit E
* 456520c 2015-02-13 (origin/foo) Commit A
* 23bfcd1 2015-02-11 Commit B
* b0bdd18 2015-02-12 Commit C

为什么看起来我的本地foo领先于origin/foo? D和E都不是我的提交，我只是从origin中删除了这两个提交-我希望在这一点上仍然有HEAD == foo == origin/foo.

Why does it look like my local foo is ahead of origin/foo? Neither D nor E are my commits, I just pulled both of those from origin - I'd expect at this point to still have HEAD == foo == origin/foo.

推荐答案

pull --rebase之前的内容是:

x--x--x (foo, HEAD, origin/foo)
       \
        y--y (actual origin/foo)

pull --rebase时，您要求在origin/foo上重播本地提交:
foo在origin/foo处重置/签出(在FETCH_HEAD中提取)，并且由于您的提交'x'已经是新更新的FETCH_HEAD的一部分，因此foo只是快速转发的:

When you pull --rebase, you are asking to replay your local commits on top of origin/foo:
foo is reset/checked out at origin/foo (which is fetched in FETCH_HEAD), and since your commits 'x' are already part of the new updated FETCH_HEAD, foo is simply fast-forwarded:

x--x--x--y--y (foo, HEAD, FETCH_HEAD)
      |
 (origin/foo)

origin/foo未更改 的事实通常是 git早于1.8.4 (例如在 Ubuntu Precise 12.04 中找到，并附带旧的git-core 1.7.9.5)

The fact that origin/foo has not changed is typical of a git older than 1.8.4 (found for instance in Ubuntu Precise 12.04, which comes with and old git-core 1.7.9.5)

一个简单的git fetch应该足以更新origin/foo，而不仅仅是FETCH_HEAD.

A simple git fetch should be enough to update origin/foo, and not just FETCH_HEAD.

较新的git(1.8.4+)将同时更新FETCH_HEAD和origin/foo，从而使其他git fetch成为多余.

A more recent git (1.8.4+) would have updated both FETCH_HEAD and origin/foo, making the additional git fetch redundant.

注意:对于Git 2.12(2017年第一季度)，这种情况(pull --rebase)将是一个简单的快进合并.

Note: with Git 2.12 (Q1 2017), this case (pull --rebase) will be a simple fast-forward merge.

请参见提交33b842a (2016年6月29日)由 Junio C Hamano合并-gitster-在

See commit 33b842a (29 Jun 2016) by Junio C Hamano (gitster). ^{(Merged by Junio C Hamano -- gitster -- in commit 2fb11ec, 19 Dec 2016)}

pull:快进"pull --rebase=true"

"git pull --rebase"在获取以下内容后始终运行"git rebase" 承诺充当新的基地，即使新的基地是 当前HEAD的后代，即我们尚未完成任何工作.

pull: fast-forward "pull --rebase=true"

"git pull --rebase" always runs "git rebase" after fetching the commit to serve as the new base, even when the new base is a descendant of the current HEAD, i.e. we haven't done any work.

在这种情况下，我们可以快速前进到新的基地而无需 调用变基过程.

In such a case, we can instead fast-forward to the new base without invoking the rebase process.

这篇关于git pull --rebase导致意外的图形的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！