Git：从生产中恢复（或重新设置基-i）错误提交

我们一直在使用作为我们小型开发团队分支和合并的基础<代码>母版被推到

暂存

（供审查），然后是

生产

。一个未经批准的功能在登台时被卡住，而热修复程序（可以说）从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恢复602bd9d

git-rebase-i c341b06

并重写我的历史记录，而不使用违规的

602bd9d

commit

我没有太多的历史“重写历史”，因为将重写的历史推到共享的Git回购中是非常禁忌的

存在合作者，

origin/master

包含不成熟代码。什么是最干净、最安全的方法来让master完成一次提交（从而停止生产）？寻找任何建议/陷阱

---

谢谢

只需恢复提交。将重写的历史推到共享回购协议上是“禁忌”的，这是有原因的；在这种情况下，您必须确保所有使用过repo的人都执行

git fetch

，然后执行

git重置--hard origin/master

。唯一应该将重写推送到服务器的时间是在需要时，例如，在意外提交机密信息时

我的经验法则是——如果有3个以上的开发人员需要从重基恢复，那么只需执行恢复。如果您的开发人员都能胜任Git，那么问题就小得多了。如何“从重基中恢复”？如果它只是强迫一个git拉动，那没关系。但是，如果它要破坏所有正在开发的功能分支，那么它可能不是一个新手。rebase手册页面中有一个叫做“从上游rebase恢复”的部分记录了这个过程。我个人并不觉得这很难，但我的很多同事都无法独自完成。如果服务器上有额外的分支，则会使事情进一步复杂化。我一直在未发布的作品上使用rebase，但实际上从未在共享分支上使用过。除非有非技术原因（如法律原因）无法提交，否则只需将其还原即可。即使用户能够处理重基，为什么还要麻烦呢？不要介意，您有充分的理由不想删除某个时候在生产中使用的代码。