恢复一个混帐合并提交，然后恢复恢复 [英] Reverting a git merge commit, then reverting the revert
问题描述
我们的团队使用Github Pull Request来管理我们的工作流程，就像描述的那样这里。在手动检查已接受的合并请求后，我们偶尔需要恢复合并，因为它尚未准备好部署到我们的生产服务器。
然而，如果开发人员尝试再次发出合并请求，它不会识别这些更改已被还原，并看到提交已经在主分支中。它只会包括自恢复以来他们最近的提交，但我们真正想要的是重新引入所有提交的提交，以及他们的新作品。换句话说，我们喜欢重新发布原始Pull请求的方式。由于Github不支持此功能（即既不恢复合并，也不撤销/重新发布一个原始的拉取请求），我目前正在恢复已还原的合并。这感觉不对。
我可以使用其他方式在git中实现相同的目标吗？ （或Github，如果可能的话）
我认为你的问题在这里产生，因为当你处理pull请求时， '选择自动将它们合并到GitHub上。在处理拉取请求的三种建议方法中，在文档中描述 '使用最后一个（自动合并），它只是最近实施的 。就我个人而言，我认为这只适用于明显正确的无关紧要的请求。对于任何更复杂的事情，我想要使用第一种方法，即将请求者的存储库添加为新的远程 $
- b $ b
- 从该远程获取
- 尝试合并
- 仔细测试
- 如果您满意，结果为
这意味着合并后的版本只有在您测试过并决定推送后才会公开。如果你不想要，你可以重新设置你的主分支到它以前的位置。
兴趣，可能值得更多地说出如果你最终不得不恢复令人遗憾的合并，但仍想要重新合并该分支的更高版本，那么会发生什么情况。虽然它可能会感觉错误，但据我所知，处理这种情况的最简单方法的确是恢复回复。您可以在Pro Git博客的这篇文章中找到关于此问题的更多讨论和对同样问题的另一个讨论，Linux Torvalds可能也有帮助。
Our team uses Github Pull Requests to manage our workflow, much like what is described here. Upon manually reviewing the accepted Pull Request, we occasionally need to revert that merge because it isn't ready for deployment to our production servers.
However, if a developer attempts to issue a Pull Request again, it does not recognize these changes were reverted and sees that the commits are already in the master branch. It only will include their recent commits since the revert, but what we really want is to reintroduce ALL of the commits there were reverted, plus their new work. In other words, we like a way to reissue the original Pull Request.
Since Github doesn't support this feature (i.e., neither reverting a merge, nor undoing/reissuing an original pull request), I am currently reverting the reverted merge. This feels wrong.
What other ways could I use to achieve the same goal in git? (or Github if it's possible)
解决方案I think that your problem here arises because when you are dealing with the pull requests, you're choosing to automatically merge them on GitHub. Out of the three suggested ways of dealing with pull requests described in the documentation you're using the last one ("Auto Merge"), which was only recently implemented. Personally, I think this is only appropriate for trivial pull requests which are obviously correct. For anything more complex, I would want to use the first approach, i.e.
- adding the requester's repository as a new remote
- fetching from that remote
- trying the merge
- testing carefully
- pushing the result if you're happy
That means that the merged version is only public once you've tested it and decided to push. If you don't want to, you can just reset your master branch to its previous position.
As a matter of interest, it might be worth saying more about what happens if you do end up having to revert a regrettable merge, but still want to have the option to re-merge a later version of that branch. Although it might feel wrong, as I understand it the easiest way to deal with that situation is indeed to revert the revert. You can find more discussion of this issue in this post from the Pro Git blog and another discussion of the same problem by Linux Torvalds that might also be helpful.
这篇关于恢复一个混帐合并提交，然后恢复恢复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
