git rebase --skip是做什么的？ [英] What exactly does git rebase --skip do?

问题描述

我只是做了一个 git pull --rebase origin master ，并且发生了冲突。

首先，这个冲突是在一个我没有触及的文件中，大约有10次提交。为什么会发生这种情况？

然后我意外地输入了 git rebase --skip ，并且'跳过了' 。

担心我跳过了一个提交，我检查了一个新版本的主分支，并在分支之间进行了一次差异转换，新的主分支。差异中显示的唯一更改是最新的提交，并查看日志，跳过的修补程序显示在提交历史记录中。

任何人都可以解释这里发生了什么？

承诺。如果在同一个rebase期间在稍后的冲突中运行 rebase --abort ，则跳过的提交也会被撤消。

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

你应该确保你没有删除一个重要的改变你的;）（使用reflog返回到rebase之前的状态）

I just did a git pull --rebase origin master and there was a conflict.

Firstly, this conflict was in a file that I hadnt touched, and was about 10 commits back. Why does this happen?

I then accidently typed git rebase --skip, and it 'skipped that patch'.

Worried that I had skipped a commit, I checked out a new version of the master branch and did a diff between the branch that I did the rebase on, and the new master branch. The only changes that show up in the diff are the latest commit, and looking at the log, the patch that was 'skipped', shows up in the commit history.

Can anyone explain what is going on here?

解决方案

It does what it says, it skips a commit. If you run rebase --abort at a later conflict during the same rebase, the skipped commit will be reverted too of course.

If your change already existed upstream, Git will not be able to apply your commit (but usually should skip it automatically, if the patch is exactly the same). Your own commit will be skipped, but the change will still exist in current HEAD, because it was already applied upstream.

You should really make sure you did not remove an important change of yours ;) (use the reflog to go back to the state before the rebase)

这篇关于git rebase --skip是做什么的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！