git rebase 后丢失提交

missing commits after git rebase

提问by jonasnas

A-B-C  Master
 \D-E  Feature

After executing a rebasecommand git checkout feature-> git rebase masterall my commits from featurebranch disappears so I have A-B-Ccommits. featurebranch looks like masterafter rebasing. Also rebasing doesn't give any error but it doesn't show 'commits are replayed' message which I think usually it shows during rebasing. Do you know what could have caused this behaviour?

执行rebase命令后git checkout feature->git rebase master我从feature分支的所有提交都消失了，所以我有A-B-C提交。feature分支看起来像变基master后。此外，变基不会给出任何错误，但它不会显示“提交被重播”消息，我认为通常它会在变基期间显示。你知道是什么导致了这种行为吗？

Once I've noticed my commits disappeared I ran the following command to find the missing code in git history: git rev-list --all | xargs git grep expressionThis command returned a commit hash but this hash was not present when I run git log (because of rebase). If I do git reset --hard missing-hashI can see the original (correct) featurecode again. Running rebase masterrecreates same problem again.

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

EDIT:I've just noticed I have some extra commits like WIP on commit-messageand index on commit-messagewhen I do git reset --hard missing-hashCan it be related with git stash / git stash apply

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

采纳答案by eddiemoya

Just so were on the same page about how rebases work. In your example, git is basically trying to add and D and E after C one by one. The rebase commits on D & E will not be the originals, instead they will be clones with new hashes. The original will still exist, but will simply be dangling with no branch referencing them (garbage collection will delete them eventually). After a rebase, you can see the "original" version of the rebased commits by looking at git log ORIG_HEAD

关于 rebases 的工作原理也是如此。在您的示例中，git 基本上是尝试在 C 之后一一添加和 D 和 E。D & E 上的 rebase 提交将不是原始提交，而是具有新散列的克隆。原始文件仍然存在，但只是悬空，没有分支引用它们（垃圾收集最终将删除它们）。变基后，您可以通过查看变基提交的“原始”版本git log ORIG_HEAD

However, exceptions can take place in this process. Git will intelligently skip any commits that are already in the "base" (master, in this case) - this can happen a branch gets merged, reverted, then remerged.

但是，在此过程中可能会发生异常。Git 会智能地跳过任何已经在“基础”（在这种情况下是 master）中的提交——这可能会发生一个分支被合并、恢复，然后重新合并。

It will also skip any commits if it finds that the commits being added to the base identically match, in their content - commits that are already in the history - even if the hashes are different - this can happen if a branch is merged, rebase, then merged again.

如果它发现添加到基础的提交在其内容中完全匹配 - 已经在历史记录中的提交 - 即使散列不同 - 如果分支被合并，重新设置，这可能会发生，它也会跳过任何提交，然后再次合并。

I suspect one of a few situations.

我怀疑几种情况之一。

1. Your feature branch may have already been merged into master.
2. Your feature branch already matches master.

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

1) git branch --contains feature

1) git branch --contains 特性

This will list all branches which contain your feature branch in their history. If master is in that list, then your branch is already merged. Nothing to do here.

这将列出在其历史记录中包含您的功能分支的所有分支。如果 master 在该列表中，那么您的分支已经合并。无所事事。

Theres a few reasons this might not seem right though.

有几个原因这可能看起来不对。

One reason is that you may not see your changes in the current master code. This could be for a few reasons. If the branch had been previously merged into master, and then reverted, then the commits are already there, but negated - even if remerged those reverted commits will not return - you would need to revert the actual revert commit.

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

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

2) git 结帐功能；git rebase --keep-empty 功能

The --keep-empty will force git to keep your commits even if they don't contain any "new" content or changes. This isn't a fix or workaround, but if you see these commits in your history after doing this - then it means your commits arent being lost. They are getting skipped intentionally. You can decide for yourself if you want to keep the empty ones.

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

If this is the case, then I would look to see if this branch has been merged in the past. It may have been merged as part of a different branch for example. Maybe Bob thought he needed your work from the featurebranch in his bobs_featurebranch - his branch made it to master before yours and now your branch is basically irrelevant. Another case might be that it was merged in the past into master, and then reverted. The answer here is to revert the revert commit itself - sort of like hitting redo after hitting an undo.

如果是这种情况，那么我会查看该分支过去是否已合并。例如，它可能已合并为不同分支的一部分。也许 Bob 认为他需要你feature在他的分支中的bobs_feature分支的工作 - 他的分支在你的分支之前就已经掌握了，现在你的分支基本上是无关紧要的。另一种情况可能是它在过去被合并到 master 中，然后又恢复了。这里的答案是还原还原提交本身 - 有点像在点击撤销后点击重做。