历史会是这个样子:
*--*--*--C---A--B [master]
\ /
*--*--*--*--* [contract]
哪里A
是坏的合并,B
是复归,并C
是合并前的最后一次好提交。 (要确定什么是散列是你的情况,例如做git log --oneline --decorate
。)
当你恢复合并,Git采取这意味着你不希望这些改变重新合并到存储库。如果您刚从命令行工作,解决方案是恢复恢复,请参阅:Re-doing a reverted merge in Git。但是,这会阻止您使用GitHub的PR UI。
相反,您可以重写历史记录。强制要求警告:对于使用存储库的其他开发人员,重写历史记录可能会带来危险和破坏性。一定要清楚地表明你正在这样做。
如果您尚未切换到master
(git checkout master
)。
如果你没有从contract
从A
,B
C
抛开之后的任何提交,任何提交,然后执行:
git reset --hard HEAD~2
或者:
git reset --hard C
然后你的历史看起来像这样:
*--*--*--C [master]
\
*--*--*--*--* [contract]
如果在此期间再次承诺更多,那么您将不得不改名。这样做:
git rebase -i X
在rebase-todo
文件,删除对应contract
分支任何线路,还有复归提交B
。(在我的测试中,没有显示合并提交A
,但如果是,则将其删除。)如果存在任何冲突,请修复它们并继续使用git rebase --continue
。
你完成了改写历史后,执行:
git push --force-with-lease origin master
你master
分支现在没有证据证明合并曾经发生过,并从contract
公关应该显示所有预期的提交。
自恢复或合并与恢复之后是否还有其他任何提交? –
没有提交合并,然后恢复。在合并和恢复后只有两个,但这两个提交合同都没有主 – LearningJrDev