我正在处理我的功能分支，经过审查后，将其 merge 到development 中进行部署。后来，一位同事决定发布一个版本，并将他的和我的 merge 到 master 中。在部署时，他意识到他的代码有问题并恢复了 master。
在我们的 fork-and-pull 流程中，这意味着现在 development 和 master 都被还原了。
当我今天早上来的时候，我像往常一样从开发中重新定位，后来才知道有一个恢复。
现在，我正尝试从原始 feature 分支 中cherry-pick 我的工作，结果发现由于还原，它给了我“空提交消息”。
- 这是因为还原是我之前提交的镜像吗？
- 有没有办法还原还原？ (让我头疼)
- 既然我已经重新设置了基数，是否仍然可以让我的提交显示在 diff 中
非常感谢任何帮助。
最佳答案
Cherry-pick 和 rebase 检查提交的补丁 ID(基本上是更改的哈希)并且已经看到分支上存在更改，因此它不会选择它。 rebase 有时可以工作，因为文件中的更改可能导致实际差异发生一点变化——导致不同的补丁 ID——但对你来说情况似乎并非如此。
您可以“还原还原”，尽管这会重新引入您的同事介绍的错误信息。然后你需要恢复你的同事所做的错误提交。返回的次数很多，而且要保持直线行驶也很困难，所以请慢慢来，让某人坐在您身边，以确保您不会错过任何东西。
另一种选择可能是通过执行 git show COMMIT_ID | 重放您的提交。 git 应用。这会将差异重新应用到您的工作树。只要你的树是干净的，你就可以使用 git commit -C COMMIT_ID 来重新使用来自原始提交的消息。您或许可以使用 git format-patch 和 git am 来避免额外的步骤。
关于git - 还原后如何挑选提交？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23681754/