我正在将branch2重新定位到更新版本branch1上。有一些冲突，所以我进行了合并并git add编辑了冲突的文件。但后来没有按git rebase --continue我按下我的终端而没想到按下git rebase --skip。冲突是否会成功解决，或者由于--skip标志，git会恢复到其中一个版本？
答案 0 :(得分：1)
rebase代码相当棘手（在2.13中，交互式rebase现在主要由音序器处理，而不是由this.customerService.getCustomers()
.subscribe( customers => {
this.customers = customers
});
}
处理，尽管这是由 git-rebase--interactive.sh驱动的 。幸运的是，git-rebase--interactive.sh非常简单，部分由顶级shell脚本git-rebase.sh, here和here处理。在继续执行特定类型的rebase（--skip，--skip或git reset --hard HEAD的跳过操作之前，使用am会让Git运行interactive：前两个使用merge进行交互和合并rebase，最后一次使用git rerere clear进行git am --skip - 样式的非交互式非合并rebase）。
这意味着Git抛弃了你的谨慎决议，然后继续尝试挑选下一次提交，并从那里继续使用rebase。
如果你在这些解决方案中付出了大量的工作，你可以尝试恢复现在悬空的blob（请参阅Recover dangling blobs in git - 请注意，接受的答案是对哈希ID使用am，哪个有用，但是如果你有很多要搜索的话，那就是simpler to look in the .git/lost-found/other directory;添加的合并文件将在那里，与存储库中剩余的所有其他悬空blob混合在一起，这可能是相当多的）。您可能也希望中止或撤消您的rebase。
请注意，您可以保存此rebase的最终产品或产品。如果你在这里有其他好的解决方案，这可能会有用。在执行任何操作之前，只需设置分支或标记名称以指向当前的git show提交：
HEAD回到你开始这整个基础之前的状态。然后，您可以使用git rebase --abort # if it's still in progress, or
git reset --hard ORIG_HEAD # if it's finished now
引用现有的已完成的rebase部分从该提交向后计数，或运行name~<number>以查找带有其分辨率的rebase复制的提交，并切断并超过其哈希ID。