我们有一个不会破坏提交历史的政策，因为它是一个大项目。所以我通常做的就是在我的功能分支上，每天push -f origin featbranch，一旦完成，我就会发布PR。
这种做法让我今天受损了。
我完成了featbranch的工作。在成功运行所有测试等之后，我做了第一次push -f origin featbranch。 origin是我自己克隆的我们工作的回购，upstream是PR发给我的回复。
然后我回忆起upstream/master可能已经发生了变化，所以为了让我的featbranch保持最新，我想要改变：
git fetch upstream master
git rebase upstream/master
git push -f origin featbranch
没有错误。我认为一切都还可以（我只是仔细检查了所有的测试......等等），但可能会感到非常沮丧，我现在意识到我最近的所有变化都已丢失。
我现在有一种奇怪的情况，我不知道发生了什么。事实上，我featbranch上的第一次提交似乎已经离开了：featbranch中有一个绝对不在upstream/master的文件。所以我感到很困惑，不知道这里发生了什么，github说这个分支的提交是从13天前我实际推动昨天。
我想，由于-f origin featbranch，我的最新提交无法恢复 - 不是在本地，而是在github上。从现在开始，我将忽略上述政策，并且总是每天推动，但不会强迫。不过我想了解这里发生的事情。
答案 0 :(得分：2)
git有恢复丢失提交的方法：git reflog
此外，正如您自己收集的那样，git push的-f选项不应该是您正常工作流程的一部分。如果要保持提交历史记录清洁，请考虑使用this。
答案 1 :(得分：2)
由于您可能已经在这里学到了很多困难，因此常规使用push -f的工作流程很危险。 push -f没有提供错误不意味着操作是安全的。这就是为什么我经常低调投票推荐推力而不解释风险和其他影响的原因。
但是，你可能不会像想象的那样迷失。
我在您发布的程序中看不到会导致您描述的症状的任何内容。我怀疑采取了一些措施，这里没有明确说明。但无论哪种方式，强制推动都不会改变你的本地状态。您仍然可以使用reflog来尝试恢复您的工作。
git reflog featbranch
这将显示featbranch引用的历史记录，它为您做了两件事：
首先，每次ref移动时，生成的reflog条目都会记录 移动的原因;所以也许你可以看到实际造成明显失去工作的原因。
其次，参考日志还记录＆＃34;＆＃34;之前和之后每次ref移动时提交ID - 这意味着只要它没有从日志中滚出，您就可以恢复任何以前的状态。实际上，reflog为ref的每个先前状态提供了一个方便的名称
git checkout featbranch@{3}
表示要在最近3次更改之前查看featbranch。 reflog命令将告诉您与每个这样的状态相关联的名称。