考虑以下情况。
项目X有一些活跃的上游开发。为了我们自己的内部目的，我们正在研究项目X的分支。由于我们没有对项目X的Git仓库的写访问权限，因此我们在自己的服务器上创建了自己的Git仓库克隆。在本地计算机上工作时，所有同事都将该克隆的存储库用作origin。
为了能够将项目X的上游开发持续集成到我们的fork中，我们不会触及master服务器上的origin分支。 （设置master分支以跟踪项目X的Git仓库的master分支。）而是我们在分支my_master上工作，我们在其中提交更改（并将它们推送到origin服务器）。在我们的origin服务器上，我们可以定期将项目X的最新提交提取到master分支。然后，我们可以切换到my_master分支，并通过运行git merge master将项目X的最新开发合并到我们自己的分支中。
好。但是，现在，在我们的fork上工作的同事意外地在master分支上进行了大量提交，而不是在my_master分支上进行，并将它们推送到origin服务器。他注意到他的错误，在本地切换到my_master并将他的master分支合并到他的my_master分支中，以便这些更改存在于正确的分支上，并推送它。
所以my_master分支现在很好，但master分支包含一些不应该存在的补丁。当然，我们可以通过创建＆＃34;还原提交来恢复这些更改。恢复错误的个人提交。然后，我们的master服务器上的origin分支的状态将再次看起来像项目X的Git repo上的master分支的状态。但是，它实际上包含一些恢复提交。这意味着，下次我们更新master服务器上的origin分支，并尝试将上游更改合并到我们的my_master分支中时，还将应用还原提交，并且应该在my_master分支中构建的新功能将被撤消。这是对的吗？
那我们怎么做呢？原则上，我们希望在意外提交之前将master服务器上的origin分支重置为提交。但是我们无法创建还原提交，因为这意味着master到my_master的下一次合并也会恢复my_master分支上的更改。
答案 0 :(得分：1)
首先，我建议您恢复my_master分支中的恢复提交，以在master分支中保留线性历史记录。这种方式是更安全的方式，尽管这样它们仍然会显示在提交历史中。
如果你真的希望这些提交消失，那么另一种方法就是在master中进行rebase交互以删除它们，但是然后每个人都必须重新设置基于那个错误主人的分支！
git rebase --interactive [commit hash before faulty commits]^
（不要忘记提交哈希后的^）
它将打开您的默认文本编辑器，您所要做的就是删除错误提交的行。
这样就好像他们从未发生过一样。但要小心，让他们回到my_master分支（在被master重新定位后）使用cherry-pick。然后push --force origin master，并要求每个人刷新他们的遥控器，并根据重写的master重新设置他们的工作。