背景
刷文章看到一个评论，如下：
同时贴出评论者的解决方法：
我本来是想着看是否有更好的办法，但是经过了一顿操作，发现自己还是没办法仅通过命令来完全实现合并之前的那种场景来重新解决冲突。但是因为尝试了半天，所以还是决定把勉强实现的一种解决方案提了出来。大家看下，如果觉得有更好的方案可以告诉我，我尝试下，并补充进来。
正文
感觉这种场景还挺常见，我以前虽然没怎么经历过，但是我觉得应该找个解决方案，以后万一遇到了也不用慌。
构建场景
说干就干，本地正好有git环境。所以我们省略之前的配置过程。直接先新建两个分支分别是dev/zhangsan和dev/lisi. 
然后在本地建立远程关系。
然后张三使用dev/zhangsan分支进行开发，修改了one.txt文件，如下：
然后进行代码的暂存，提交，推送，一气呵成！
张三改完以后就放假回家了。
同时，李四手里也在进行一个任务的开发，使用dev/lisi分支，同样涉及到了one.txt这个文件的修改，修改内容如下：
但是因为开发的较慢，所以还没提交，当张三改完之后不多时，李四也完成了，同样是一系列的暂存，提交，合并，推送。
然后就发现合并的时候冲突了。
有冲突就解决呗，李四一顿操作猛如虎，删除了一些，保留了一些，
还未仔细检查，结果手太快，完成了push操作。
push后，李四就反应过来自己闯祸了。张三的代码被自己搞没了，这可如何是好，此时想到是否可以revert来进行反悔操作？ 说干就干，通过git log找到刚才merge后的commitId，然后尝试执行：
报错！提示不能这么操作，因为是针对两个分支进行的merge，那你回退时肯定是选择1（zhangsan）或者2（lisi），但是发现回退到1时，2的就没了，回退到2时，1的就没了。这可如何是好？ 网上搜索相关命令，发现了一个迂回操作，使用checkout命令。
以下是相关解释：想回滚到合并后冲突的状态，但又希望保留那个冲突以便重新解决，那么直接使用
git revert并不是一个合适的方法。因为当你撤销包含冲突解决结果的提交时，Git 会尝试自动解决这个冲突并产生一个新的提交。
在这种情况下，一个更好的做法是通过检出（checkout）特定的提交哈希来还原工作目录到合并后的状态，这样你就可以重新经历冲突解决的过程：
所以只需要找到merge前的最近一次的张三提交的commitId和李四提交的commitId，然后处理即可： 执行命令后，如下所示：
重点看图示中其中一句话：If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name> 也就是说：如果你想创建一个新的分支来保留你创建的提交，你可以通过使用-c和switch命令来完成。 那就把张三提交的切换到分支zhangsan_1，命令执行如下：
同理：把李四的提交也切换到另一个分支：lisi-1
此时针对lisi-1合并zhangsan_1，重新处理冲突。
处理冲突后
此时也只是在临时分支lisi-1上完成了冲突的解决，实际dev/lisi这个分支还没处理。此时也没什么好的办法，就把这一段覆盖到dev/lisi分支上，然后再次提交。
最后尝试下来，感觉比开头提到的通过bcompare来操作没节省多少精力。也尝试了多种方法，确实没办法说直接恢复到合并之前的那种场景。
在没尝试之前，以为不是很难，实际操作下来发现，却不是这样。