A-B-C Master
\D-E Feature
执行rebase命令后git checkout feature - ＆gt; git rebase master来自feature分支的所有提交都消失了，所以我提交了A-B-C次提交。在变基之后，feature分支看起来像master。此外，变基不会产生任何错误，但它不会显示“提交已重播”消息，我认为通常它会在变基期间显示。你知道可能导致这种行为的原因吗？
一旦我注意到我的提交消失了，我运行以下命令在git历史记录中找到丢失的代码：git rev-list --all | xargs git grep expression此命令返回了一个提交哈希，但是当我运行git log时这个哈希不存在（因为变基）。如果我git reset --hard missing-hash，我可以再次看到原始（正确的）feature代码。正在运行rebase master会再次重现相同的问题。
编辑：我刚刚注意到我有WIP on commit-message和index on commit-message这样的额外提交git reset --hard missing-hash它可能与{{1}有关}}
答案 0 :(得分：6)
关于rebase如何运作的同一页面上也是如此。在你的例子中，git基本上是尝试逐个添加C和C之后的D和E. rebase承诺D＆amp; E不会是原件，而是带有新哈希的克隆。原始文件仍然存在，但只是悬空而没有引用它们的分支（垃圾收集最终将删除它们）。在变基之后，您可以通过查看git log ORIG_HEAD
但是，此过程中可能会出现例外情况。 Git将智能地跳过已经在“base”中的任何提交（在这种情况下为master） - 这可能发生分支被合并，还原，然后重新合并。
如果发现添加到基础的提交在其内容中相同匹配，它也将跳过任何提交 - 在历史记录中已经提交 - 即使哈希值不同 - 如果合并分支也会发生这种情况，rebase，然后再次合并。
我怀疑是少数情况之一。
1）git branch --contains feature
这将列出其历史记录中包含您的功能分支的所有分支。如果master在该列表中，那么您的分支已经合并。这里无事可做。
Theres有几个原因可能看起来不太合适。
一个原因是您可能看不到当前主代码中的更改。这可能有几个原因。如果分支先前已经合并到master中，然后还原，那么提交已经存在，但是否定 - 即使重新合并这些恢复的提交也不会返回 - 你需要恢复实际的恢复提交。
2）git checkout功能; git rebase --keep-empty feature
--keep-empty会强制git保留你的提交，即使它们不包含任何“新”内容或更改。这不是修复或解决方法，但如果您在执行此操作后在历史记录中看到这些提交 - 那么这意味着您的提交不会丢失。他们故意被人跳过。如果你想保留空的，你可以自己决定。
如果是这种情况，那么我会查看过去是否已合并此分支。例如，它可能已合并为不同分支的一部分。也许鲍勃认为他需要你feature分支bobs_feature分支的工作 - 他的分支在你的分支之前让它掌握，现在你的分支基本上是无关紧要的。另一种情况可能是它在过去合并为master，然后还原。这里的答案是恢复恢复提交本身 - 有点像在点击撤消后点击重做。