我已经将一个分支（功能/ b）合并为develop， 我遇到合并冲突，并且对如何解决它们做出了错误的决定。 然后，我进行了一次人工提交，以解决其他一些问题。 更多的提交进入功能/ b，然后我也将它们合并 然后我意识到自己的错误并恢复了上一次合并。
所有东西都被推到了遥控器上，并被团队拉了。
事情现在很混乱。我需要再次使开发稳定，但还需要在解决原始合并中的冲突方面再做一次。
解决这个问题的最佳选择是什么？
谢谢
我已经阅读了与此密切相关的答案，但我正在寻找更多指南：How to revert a merge commit that's already pushed to remote branch?
答案 0 :(得分：4)
这听起来确实很混乱。
我的方法是您最后的建议：在出现问题之前放弃并创建一个新的dev分支。在该分支上，您可以重做未正确完成的合并，然后选择不正确合并后完成的所有良好提交。推动并要求团队在新的dev分支上工作。
此解决方案的优势在于，如果有人在坏的dev分支上取消了提交，则他们还可以私下将它们挑选到好对象上。
答案 1 :(得分：1)
无论您做什么，都不要重置并强制使用develop，因为它与其他开发人员共享并且会变得更加混乱。
您可以还原，但是如您所见，请注意，以前合并的提交将在以后的合并中被忽略（因为历史记录未更改）。 我会重新创建功能分支，好像它是新分支一样。
您可以通过指定从哪个提交开始重新设置基准来轻松地执行重新确定基准，这在您提供的链接中进行了解释。
假设我们处于这种情况下
/B-C\(feature/1)
A-----D-E(develop)
其中A是合并之前的develop和分支的原点，C是合并时刻的feature/1分支，D是合并提交，E是修复它的尝试。
首先还原D和E，因为D是合并提交，因此您必须使用-m指定要还原到哪个父对象，它应为1，但选中（git revert D -m 1）。
然后根据提交feature/1（分支的起源）对分支A进行重新设置
git checkout feature/1
git rebase --no-ff A (no-ff to force rebase)
然后您将像这样结束：
/B-C\
A-----D-E-F(develop)
\B'-C'(feature/1)
其中F是还原的提交，B'和C'是新创建的提交。
您可以合并feature/1，就好像它是新分支一样。
答案 2 :(得分：0)
此答案假设您当前的feature/b分支看起来像这样：
feature/b: .. M -- A -- B -- C
这里M是您不需要的合并提交，然后A至C的提交来自其他开发人员，他们先是拉了分支，然后又推了。我们可以尝试将git revert用于以下范围：
git revert -m 1 HEAD~3^..HEAD
语法HEAD~3^..HEAD意味着将HEAD提交之前的提交（包括三个）还原为包含HEAD的提交。 -m 1选项告诉Git跟随分支的第一个父节点，该父节点通常是远程分支（合并的分支源为-m 2）。
请注意，有必要在此处git revert，因为您已经发布了此分支。诸如硬重置和其他更改历史记录的选择在这里并不理想。