简答(@Alex 在 cmets 中已经给出):git reset --hard HEAD^,但仅当有合并提交时(否则您只是从快进中备份一个提交)。
带解释的长版:
git pull 实际上只是 git fetch 后跟 git merge (除非你用 --rebase 覆盖,正如你所注意到的)。所以你只需要看看你是否有一个实际的合并提交:
$ git pull
Updating 171ce6f..523bacb
Fast-forward
mp.py | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 mp.py
在这种情况下,没有合并提交,只是一个快进,所以,没问题 - 没有对 rebase 的更改!如果您执行git log,您会看到缺少合并提交,特别是如果您执行下面的图形化提交。
让我们强制合并。
$ git reset --hard HEAD^
HEAD is now at 171ce6f ignore *.log files
[现在我落后了remotes/origin/master]
$ echo '# pointless comment' >> selfref.py
$ git add selfref.py
$ git commit -m 'added to force merge'
[master 260e129] added to force merge
1 files changed, 1 insertions(+), 0 deletions(-)
$ git pull
Merge made by recursive.
mp.py | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 mp.py
我们可以看到发生了这种情况,即使上面的文字丢失了,带有:
$ git log --graph --decorate --abbrev-commit --pretty=oneline
* c261bad (HEAD, master) Merge branch 'master' of [ssh url]
|\
| * 523bacb (origin/master, origin/HEAD) add multiprocessing example
* | 260e129 added to force merge
|/
* 171ce6f ignore *.log files
我们希望本地分支名称master 再次指向(在本例中)260e129。幸运的是,这真的很容易命名:
$ git rev-parse HEAD^
260e1297900b903404c32f3706b0e3139c043ce0
(当前的双父合并提交的另一个父是HEAD^2。)所以:
$ git reset --hard HEAD^
HEAD is now at 260e129 added to force merge
现在我们可以重新定位到remotes/origin/master(我将使用非常短的名称origin 来命名):
$ git rebase origin
First, rewinding head to replay your work on top of it...
Applying: added to force merge
现在graph-y单行日志显示:
$ git log --graph --decorate --abbrev-commit --pretty=oneline
* 4a0b2e2 (HEAD, master) added to force merge
* 523bacb (origin/master, origin/HEAD) add multiprocessing example
* 171ce6f ignore *.log files
从所有这些中,您应该能够弄清楚如果您运行 git pull 并且它抱怨合并失败该怎么办。 :-)