git rebase --skip到底做了什么？

107

我刚做了一个git pull --rebase origin master，就发生了冲突。

首先，该冲突存在于我未曾触及的文件中，大约有10次提交。为什么会这样？

然后git rebase --skip，我不小心键入了内容，并“跳过了该补丁程序”。

担心我跳过了提交，我检出了新版本的master分支，并在做基础的分支和新的master分支之间进行了区分。差异中唯一显示的更改是最新的提交，而查看日志的“跳过”补丁将显示在提交历史中。

谁能解释这是怎么回事？

git

— 先生
source

你怎么不小心打字git rebase --skip。也许是错误的？:)

— manojlds 2012年

哈！打算键入--abort，但由于某些未知原因，它以--skip出现。真的没有思考。:)

— mrwooster 2012年

外壳程序历史擅长于此（使您执行不想要的操作）。

— 弗洛里安·克莱因

它按照它说的去做，它跳过提交。如果rebase --abort在相同的基准迁移过程中在以后的冲突中运行，则跳过的提交当然也将还原。

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

您应该确保未删除重要更改；）（使用reflog返回到变基之前的状态）

— 针织
source

那么为什么提交仍然显示在日志中呢？为何现在丢失的提交显示在差异中？

— mrwooster 2012年

是的，冲突已经在上游解决了。由于某种原因，git rebase提出了旧的合并冲突...让我困惑的另一件事？...这是否意味着它跳过了冲突，但是应用了解决了冲突？

— mrwooster 2012年

您跳过了自己的提交，该提交与上游的提交具有相同的更改。您跳过了提交，但是更改仍然存在（因为它已经存在于上游）

— knittl 2012年

@mittal不，我不认为这--skip是要走的路。跳过将完全跳过提交，删除在该提交中所做的所有更改。

— knittl

@mittal：git rebase可以将提交从一个分支复制到另一个分支。因此，当您跳过提交时，提交的原始内容将被跳过，并且补丁不会应用（因此，对任何文件所做的所有更改都不会将其放入目标分支）。最简单的方法是建立一个简单的git存储库，其中包含两个分支，每个分支上都有多个提交，然后尝试重新设置基础并跳过提交（您可以git rebase --interactive用来指定将复制（pick）还是跳过（skip）哪些提交

— knittl