git rebase究竟是什么--skip呢？

Question

我刚刚做了一次git pull --rebase origin master,发生了冲突.

首先,这个冲突是在一个我没有触及的文件中,大约有10个提交回来.为什么会这样？

然后我意外地打字git rebase --skip,它'跳过那个补丁'.

担心我跳过了一个提交,我检查了一个新版本的master分支,并在我做了rebase的分支和新的master分支之间做了一个差异.diff中显示的唯一更改是最新提交,查看日志,"已跳过"的修补程序显示在提交历史记录中.

谁能解释一下这里发生了什么？

Answer 1

它做了它所说的,它跳过提交.如果您rebase --abort在同一个rebase期间在稍后的冲突中运行,则跳过的提交当然也将被还原.

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

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

那么为什么提交仍然出现在日志中？为什么丢失的提交现在出现在差异中？ (4认同)
是的,冲突已经在上游得到解决......由于某种原因,git rebase带来了旧的合并冲突......另一件让我感到困惑的事情是......这是否意味着它跳过了冲突,但应用了解决问题的补丁冲突？ (3认同)
您跳过了自己的提交,它与上游提交的更改相同.您跳过了提交,但仍然进行了更改(因为它已经存在于上游) (3认同)
@mittal 不，我不认为`--skip` 是要走的路。Skip 将完全跳过一次提交，删除此提交中所做的所有更改。 (2认同)
@knittl 当我们说“这个提交”时，我无法理解“这个”是什么？是本地的变化还是来自上游的变化？有来自上游的 .gitreview 更改，如果我执行“--skip”，它会接受我想要的上游更改 (2认同)
@mittal：将git rebase看作是_copying_从一个分支提交到另一个分支。因此，当您跳过提交时，提交的_original_内容将被跳过，并且不会应用补丁（因此，对任何文件所做的所有更改都不会使其进入目标分支）。最简单的方法是建立一个简单的git仓库，其中包含两个分支，每个分支上有多个提交，然后尝试重新设置基础并跳过提交（您可以使用git rebase --interactive指定要复制的提交（pick）。）或跳过（`skip`） (2认同)

Answer 2

当我知道不应该有任何冲突并且列出的冲突没有任何意义时，我自己经常会遇到这个问题。举个例子，我有几个分支，顺序如下：

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

在这样的情况下。