Git：恢复（或 rebase -i）生产中的错误提交答案

【问题标题】：Git: revert (or rebase -i) a bad commit out of productionGit：恢复（或 rebase -i）生产中的错误提交
【发布时间】：2014-10-20 23:20:29
【问题描述】：

我们一直使用GitHub flow 作为我们小型开发团队的基础，以便从master 分支和合并。 Master 被推送到 staging（供审查），然后是 production。一个未经批准的功能在暂存时卡住了，而一个修补程序可以说是从 master 分支出来的，因此包括尚未批准的暂存代码并被推送到production。从那以后，除了那个“坏”的提交之外，还有一些提交。

我们看到需要另一个共享分支，我们可以将其用于暂存，而不是假设我们可以共享 master，但是现在提出这个问题为时已晚。

我想恢复那个“坏”的提交，但不确定最好的方法。在这里和其他地方有很多关于如何做到这一点的讨论，但因为这是在生产中，我想确保我完全理解后果。

master分支的伪git日志：

* 2ebe3b7 2014-10-20 | merge a new_feature (HEAD, new_feature, master)
* 4483c83 2014-10-20 | add second feature (second_feature)
* 602bd9d 2014-10-20 | add premature feature (premature_feature)
* c341b06 2014-10-20 | add fileB
* b7ffb78 2014-10-20 | initial commit

我可以：

git revert 602bd9d
git rebase -i c341b06 并重写我的历史记录，而不会冒犯 602bd9d 提交。

我没有太多“重写历史”的历史，因为将重写的历史推送到共享的 Git 存储库是非常禁忌的。

有合作者，origin/master 包含过早的代码。从 master 中获取单个提交（从而退出生产）的最干净和最安全的方法是什么？寻找任何建议/陷阱。

谢谢！

【问题讨论】：

我的经验法则是 - 如果您有超过 3 个开发人员需要从变基中恢复，那么只需执行还原即可。如果您的开发人员都能够胜任 Git，那么问题就不会那么严重了。
“从变基中恢复”的参与程度如何？如果它只是强迫一个 git pull 没关系。但如果它要破坏正在开发的所有功能分支，那么它可能是一个非首发。
rebase 手册页中有一个名为“从上游 rebase 恢复”的部分记录了该过程。我个人并不觉得这很困难，但我的很多同事自己做不到。如果您在服务器上有其他分支会使事情变得更加复杂。我一直在我未发表的工作上使用 rebase，但几乎从不在共享分支上。
除非有非技术原因（例如法律原因）导致无法提交，否则只需还原它即可。即使用户能够应对变基，为什么还要麻烦呢？没关系，您有充分的理由不想删除在某些时候在生产中使用的代码。

标签： git heroku git-rebase master git-revert

【解决方案1】：

只需还原提交。将重写的历史推送到共享仓库是“禁忌”是有原因的；在这种情况下，您必须确保曾经使用过该存储库的每个人都执行git fetch，然后执行git reset --hard origin/master。唯一应该将重写推送到服务器的时候是当一个需要，例如当机密信息被意外提交时。

【讨论】：

恢复提交可能会在以后导致各种合并问题。假设您打算提交到分支A，但不小心提交到了master。因此，您恢复对 master 的提交并重新推送到 A。现在，稍后当您想将 A 合并到 master 时，您将遇到各种奇怪的意外行为（合并冲突、丢失代码等），只有在您第一次恢复时才会消失master 上的还原提交。