我在我的存储库中的主分支上遇到了一点情况。
一个开发者错误地将一个PR从我们的develop分支直接推到了main，然后推到了remote。我们已经应用了策略，所以这种情况不会再发生了。
在这之后，我们利用Azure DevOps中的“Revert PR”功能来反转这个PR，它创建了一个分支，撤销了所有的更改，然后将其全部合并回main。
同时，我们也必须对主分支应用一些修补程序。当尝试将这些更改回滚到development时，我意识到revert commit也会回滚，这意味着我们将丢失development中的更改。
我现在也意识到，当我们做一个从开发到主公关，这些以前推动的变化将不会再次合并回来。
我如何处理这种情况，以便在将修补程序合并回开发时不会丢失功能更改，并确保在下次我们进行正确PR时该功能返回到main？
我的假设是我需要恢复revert（git revert -m 1），但是有更好的方法吗？
3条答案
按热度按时间62lalag41#
这听起来像是你在一个棘手的情况。恢复恢复是一个选项，但它可能不是最好的一个取决于您的具体情况。
您可以采取的一种方法是从main分支中挑选修补程序并将它们直接应用于develop分支，这将允许您将修补程序保留在develop中，而不会重新引入错误地推送到main的更改，然后您可以创建一个新的从develop到main的拉取请求，其中包括修补程序和自上次合并到main以来为开发而进行的任何其他更改。
另一个选择是将main分支合并到develop中，这会将main分支中的所有更改（包括hotfix和revert）都合并到develop中。然后你可以使用Git的交互式rebase功能从develop分支中移除revert提交。这样会留下一个develop分支，其中包括hotfix和自上次合并main分支以来所做的任何其他更改，但不包括revert提交。
最后，最佳方法将取决于您的具体情况以及对开发分支和主分支所做的确切更改。查看Git历史记录并与您的团队讨论情况以确定最佳操作过程可能会有所帮助。
doinxwow2#
您有效地还原了合并，但这并没有 * 清除 * 合并。这是一种典型的情况。请参阅https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt
正如那篇文章所解释的（用Linus的话说，他是Git的作者，他应该知道），如果你恢复了一个合并提交，你就永远不能再合并来自第二个父提交的提交，因为它们已经被合并了;合并的回复 commit 删除了它对第一个父节点的 * 影响 *（如你所说的“到目前为止一切都很好”），但是它并没有撤销合并的 * 事实 *，合并的拓扑仍然是历史的一部分。
你最好的办法是重新构建PR，完全从零开始，也许通过挑选（或重定基）它的提交，以便使用不同的提交获得相同的效果。这将给予你一个新的PR，你 * 可以 * 一直合并到main。
xqkwcwgp3#
情况：
dev被合并到main（“合并X”）main上：“合并X”已还原（“提交Y”）建议：
main合并回devdev上：git revert <commit Y>（新的“提交Z”）注意：这里不需要
-m 1，因为revert“commit Y”本身只是一个常规提交，而不是合并。结果：
main中的修补程序现在也适用于devdev未丢失（已恢复的）更改，因为“commit Z”已恢复这些更改dev再次合并到main中，则将再次应用曾经还原的更改（因为它们现在来自“commit Z”）