Git rebase 到底是做什么的—— Skip 做什么？

我刚刚做了 git pull --rebase origin master测试，结果出现了冲突。

首先，这个冲突在一个我没有碰过的文件中，大约有10次提交。为什么会这样？

然后我不小心输入了 git rebase --skip，它“跳过了那个补丁”。

由于担心跳过了提交，我检查了主分支的一个新版本，并在执行 rebase 的分支和新的主分支之间做了一个区分。Diff 中显示的唯一更改是最新的提交，查看日志，即“跳过”的补丁，将显示在提交历史中。

有人能解释一下这是怎么回事吗？

111430 次浏览
小开
最佳答案

它做它说什么，它 跳过一个提交。如果在同一个重建基期间以后的冲突中运行 rebase --abort，跳过的提交当然也会恢复。

如果您的更改已经存在于上游，Git 将无法应用您的提交(但通常应该自动跳过它，如果补丁是完全相同的)。您自己的提交将被跳过，但是更改仍然存在于当前的 HEAD 中，因为它已经应用于上游。

您应该确保没有删除您的重要更改;)(使用 reflog 返回到 rebase 之前的状态)

小开

当我知道不应该有任何冲突和列出的冲突没有任何意义的时候，我自己也经常碰到这种情况。举个例子，我有几个分支，顺序是这样的:

A --> B --> C --> D --> E ...

分支 D 中的一个修改是添加一个文件，我意识到在分支 B 中添加该文件更有意义。我照做了

  git switch B
git checkout B -- path/to/new/file
git commit --amend --no-edit

然后我做到了

  git switch C
git rebase B

这个很好用，但是当我这么做的时候

  git switch D
git rebase C

有冲突，我可以手动修复，但我也发现我可以

  git rebase --skip

然后一切都很好

  git switch E
git rebase D

同样的冲突也发生了，我可以手动修复它，也可以跳过它得到相同的结果。

我仍然在试图理解为什么这些冲突有时会发生，为什么有时候这样做是有效的

  git rebase --skip

在这种情况下。

小开

它跳过了承诺。在交互式基底中，如果您放弃提交，并跳过合并冲突，则该提交将被删除。

^ eee pick
| ddd pick
| ccc drop
| bbb drop
| aaa pick

如果存在合并冲突，则为 commit: ddd。如果你运行: git rebase --skip git 会说: could not apply ddd.和你的分支会像这样:

^ eee
| aaa

注意: eee实际上会被重写为一个不同的提交 ID。


提交答案