恢复 git merge 提交，然后恢复恢复
我们的团队使用 Github Pull 请求来管理我们的工作流程，就像此处描述的。在手动检查已接受的拉取请求后，我们有时需要恢复该合并，因为它尚未准备好部署到我们的生产服务器。
但是，如果开发人员尝试再次发出拉取请求，它不会识别这些更改已恢复，并且会看到提交已经在主分支中。它只包括他们自恢复以来最近的提交，但我们真正想要的是重新引入所有已恢复的提交，以及他们的新工作。换句话说，我们喜欢一种重新发出原始 Pull 请求的方法。
由于 Github 不支持此功能（即既不恢复合并，也不撤消/重新发出原始拉取请求），因此我目前正在恢复恢复的合并。这感觉不对。
我还可以使用哪些其他方法在 git 中实现相同的目标？ （或者如果可能的话 Github）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你出现问题的原因是当你处理拉取请求时，你选择在 GitHub 上自动合并它们。在文档中描述的处理拉取请求的三种建议方法中，您可以正在使用最后一个（“自动合并”），它最近才实现。就我个人而言，我认为这仅适用于明显正确的琐碎拉取请求。对于任何更复杂的事情，我想使用第一种方法，即
这意味着合并的版本仅公开一次你已经测试过并决定推动。如果您不想，可以将 master 分支重置到之前的位置。
有趣的是，如果您最终不得不恢复令人遗憾的合并，但仍然希望可以选择重新合并该版本的更高版本，那么可能值得更多地讨论会发生什么分支。虽然这可能感觉不对，但据我了解，处理这种情况的最简单方法确实是恢复恢复。您可以在 Pro Git 博客的这篇文章 和 相同的另一个讨论Linux Torvalds 提出的问题 可能也有帮助。
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.
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.
我建议你们采取不同的方法。您的恢复和恢复恢复工作流程对我来说似乎非常令人困惑。您试图解决的实际问题可以采用不同的方式来解决。
我建议您更改工作流程以使用两个分支。一个稳定分支 (
master) 和一个开发分支 (develop)。所有工作都进入develop分支，或进入单独的主题分支。拉取请求始终针对develop分支提交，然后在获得批准后合并到develop中。master最初是从develop分支出来的。一旦develop处于稳定状态，您就将其合并到master中。master是当前的稳定版本。这大致基于 nvie 的“成功的 Git 分支模型”。
I would suggest you guys take a different approach. Your workflow of reverting and reverting reverts seems very confusing to me. The actual problem you are trying to solve can be tackled differently.
I suggest you change your workflow to use two branches. One stable branch (
master) and one development branch (develop). All work goes into thedevelopbranch, or into separate topic branches. Pull requests are always filed against thedevelopbranch, then merged intodevelopwhen approved.masteris initially branched off ofdevelop. As soon asdevelopis in a stable state, you merge it intomaster.masteris the current stable release.This is loosely based on nvie's "A successful Git branching model".
如果您按照每个功能建立一个分支，则可以使用您喜欢的功能重建候选版本。您不需要“恢复合并”：
进一步阅读：https://plus.google.com /109096274754593704906/posts/R4qkeyRadLR
请参阅评论以了解更多信息 洞察力。它对我们来说非常有效。
If you get a branch-per-feature regiment going, you can rebuild a release candidate with what features you like. You will not need to "revert a merge":
further reading: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
Please see the comments as well for additional insight. It works really well for us.