混帐后失踪提交重订

Question

A-B-C Master 
\D-E Feature 

git checkout feature执行rebase命令后 - 从feature分支>git rebase master我所有的提交消失了，所以我有A-B-C提交。 feature分行在重新绑定后看起来像master。另外重新绑定不会给出任何错误，但它不会显示'提交重播'消息，我认为它通常会在重新绑定期间显示。你知道可能导致这种行为吗？

当我发现我的提交消失后，我运行以下命令在git历史记录中查找缺少的代码：git rev-list --all | xargs git grep expression该命令返回一个提交哈希，但是当我运行git log（因为rebase）时，这个哈希不存在。如果我做git reset --hard missing-hash我可以再次看到原始（正确）feature代码。运行rebase master再次重现相同的问题。

编辑：我刚刚发现我有一些额外提交类似WIP on commit-message和index on commit-message当我做git reset --hard missing-hash可以将其与git stash/git stash apply

Answer 1

正是这样是如何变基工作在同一页上有关。在你的例子中，git基本上试图在C之后添加D和E。 D & E上的rebase提交不会是原始文件，而是它们将是具有新哈希值的克隆。原始文件仍然存在，但只是没有引用它们的分支而摇晃（垃圾回收最终将会删除它们）。衍合后，你可以通过看git log ORIG_HEAD

但是看到衍合的提交的“原始”版本中，异常可以发生在这个过程中。 Git会智能地跳过已经在“基础”（本例中为主）的任何提交 - 这可能发生在分支合并，恢复，然后被重新分离。

它也会跳过任何提交，如果它发现提交被添加到基地完全匹配，在他们的内容 - 提交已经在历史 - 即使哈希是不同的 - 这可能发生，如果一个分支是合并，rebase，然后再合并。

我怀疑的几种情况之一。

1. 您的功能分支可能已经合并为主。
2. 您的功能分支已经与主人匹配。

1）git的分支--contains功能

这将列出包含在他们的历史的特性分支的所有分支。如果主人在该列表中，那么您的分支已经合并。在这儿无事可做。

的Theres几个原因，这可能似乎并不正确，虽然。

原因之一是，你可能不会看到在当前主代码更改。这可能有几个原因。如果该分支先前已经合并到master中，然后恢复，那么提交已经存在，但是否定 - 即使这些已还原的提交不会返回 - 您需要还原实际的还原提交。

2）git checkout feature; git rebase --keep-empty feature

--keep-empty会强制git保持提交，即使它们不包含任何“新”内容或更改。这不是一种解决方法或解决方法，但是如果您在执行此操作后在历史记录中看到这些提交 - 那么这意味着您的提交不会丢失。他们故意跳过。你可以自己决定，如果你想保留空的。

如果是这样的话，那么我会看看这个分支是否过去合并过。例如，它可能已被合并为不同分支的一部分。也许鲍伯认为他需要你在bobs_feature分支中的feature分支 - 他的分支在你的分支之前掌握了它，现在你的分支基本上是不相关的。另一种情况可能是它在过去被并入了主人，然后被还原了。这里的答案是恢复恢复提交本身 - 有点像点击撤消后重做提交。