我遇到了一个问题，刚刚找到了我的同事，我想知道这个问题的最佳git工作流程。
假设我们有两个分支A和B.现在我们在A和B中都改变了一些文件（foo.c），所以当我们将B合并到A时，我们会发生合并冲突。现在让我们说一些开发人员搞砸了，让分支A处于破碎状态，错误也在foo.c中，但在一条未合并的行中。
我看到了处理这种情况的一些可能性：
存储待处理的合并，修复A上的问题，提交然后再次应用合并。但是在这一点上，我不确定如何为foo.c所做的更改处理正确的合并策略。破碎的部分可能会影响我所做的一些事情，因此我没有看到解决冲突的明确方法。
撤消合并，修复A上的问题，然后重做整个合并。但是我可能已经解决了其他冲突，所以这可能会失去很多工作。
拿--theirs / - 我们的文件版本，完成合并，修改更改，樱桃挑选已丢失的更改。然而，我会有两次更改。
其他一些我无法想到的解决方案。
所有这些解决方案让我感到有点不满意。根据我的惯常经验，我可能会选择1，但我绝对不确定。
你会如何处理这种情况？
答案 0 :(得分：4)
您无法隐藏未提交的合并。选项1立即不在列表中。
就清洁历史而言，选项2的变体最佳。 Git有能力记住冲突解决方案;它只是默认禁用。您可以启用它：git config --global rerere.enabled。根据需要解决冲突。通常你会提交合并，Git会记录你解决冲突的方式。由于您实际上并不想提交合并，因此您只需运行git rerere即可立即记录冲突解决方案而无需提交。 （或者，如果你继续并提交了合并，你可以git reset --hard HEAD^，重置到它之前。冲突解决仍然会被记住。）
然后，您可以在分支A中修复问题，然后重做合并。 Git将重新使用 re 有线冲突重新解决方案。它仍然会被标记为未合并，因此您有机会查看它并确保它做正确的事情，然后在未合并路径上运行git add并提交合并。
实际上，我对选项3不清楚。你为什么要挑选？听起来foo.c仅在分支A中被破坏，这是你要合并的分支，所以这一切都在分支A中。所需的历史是错误修正，然后是合并;如果您改为继续合并然后解决问题，那么您只需要切换两次提交的顺序。在任何情况下，都没有必要进行重复提交 - 如果您澄清，我可以帮助避免这种情况！