我刚刚执行了git pull --rebase origin master
,然后发生了冲突。
首先,这个冲突出现在我没有修改过的文件中,而且大约是10次提交之前的版本。为什么会这样呢?
接着,我误输入了git rebase --skip
,它“跳过了这个补丁”。
担心自己跳过了一个提交,我检出了主分支的新版本,并在我进行变基的分支和新的主分支之间进行了差异比较。差异只显示了最新的提交,查看日志,被“跳过”的补丁出现在提交历史记录中。
有人可以解释一下这里发生了什么吗?
我刚刚执行了git pull --rebase origin master
,然后发生了冲突。
首先,这个冲突出现在我没有修改过的文件中,而且大约是10次提交之前的版本。为什么会这样呢?
接着,我误输入了git rebase --skip
,它“跳过了这个补丁”。
担心自己跳过了一个提交,我检出了主分支的新版本,并在我进行变基的分支和新的主分支之间进行了差异比较。差异只显示了最新的提交,查看日志,被“跳过”的补丁出现在提交历史记录中。
有人可以解释一下这里发生了什么吗?
它的作用就是如其所说,跳过一个提交。如果在同一次 rebase 过程中后期出现冲突,您运行 rebase --abort
命令时,被跳过的提交也将被还原。
如果你的更改已经存在于上游,Git 将无法应用你的提交(但通常会自动跳过它,如果补丁完全相同)。你自己的提交将被跳过,但是该更改仍将存在于当前 HEAD 中,因为它已经被应用到了上游。
您真的应该确保没有删除您的重要更改 ;) (使用 reflog 回到 rebase 之前的状态)
--skip
是正确的方法。Skip 会完全跳过一个提交,放弃该提交中所做的所有更改。 - knittlgit rebase
看作是将一个分支的提交复制到另一个分支。因此,当您跳过一个提交时,原始提交的内容将被跳过,补丁不会应用(因此对任何文件所做的更改都不会进入目标分支)。最简单的方法是设置一个简单的git存储库,其中包含两个分支,每个分支上有多个提交,然后尝试rebase并跳过一个提交(可以使用git rebase --interactive
指定要复制(pick
)或跳过(skip
)哪些提交)。 - knittl当我知道不应该有任何冲突,而列出的冲突也毫无意义时,我经常会遇到这个问题。举个例子,我的分支顺序如下:
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
在像这样的情况下。
它跳过了该提交。在交互式 rebase 中,如果您删除了提交并跳过了合并冲突,则该提交将被删除。
^ eee pick
| ddd pick
| ccc drop
| bbb drop
| aaa pick
git rebase --skip
,git 将会提示:could not apply ddd.
,并且您的分支将会变成这样:^ eee
| aaa
eee
将被重写为不同的提交 ID。
git rebase --skip
命令的?也许是输错了? :) - manojldsgit rebase --skip
在 rebase 过程中会跳过什么? - Mateen Ulhaq