前几天，我在这里呆了几个小时，因为一位同事将merge的{{1}}放入了我们正在研究的master-branch中，我记得之前曾见过前几天，有2个文件存在冲突。我/我们使用smartgit，通常，在feature-branch过程中（据我所记得），它在提交消息中写入哪些文件与前面的前导“＃”冲突。这意味着，处理冲突的人知道哪些文件存在冲突，他将处理该冲突，更改提交消息并将更改推送到服务器。但是merge之后的人们不知道哪些文件存在冲突（因为通过推动merge的文件已经解决了）。当我们在某些文件中遇到编译问题和错误时，我随后尝试了解这是由于（a）错误的merge-commit处理还是（b）其他原因引起的。我试图寻找一种可以快速轻松地使我看到的解决方案：
merge-conflict期间哪个文件有冲突？merge个决定（对于问题1中的文件，因为您知道许多其他文件也会更改...）？merge conflict处理引起的...我只想快速“淘汰”并知道是否存在编译错误意外的merge-conflict决策错误引起的... 如果有许多文件merge，事情就会变得复杂（因为许多文件已经/将要立即更改）。我在这里有一个“部分解决方案”（这不是“真正的”解决方案），但我认为这是一段漫长的旅程：
merged之前checkout进行提交。merge。这将告诉我冲突的文件。merge HEAD（我在哪里，从步骤2中丢弃了多余的“本地” checkout，所以我回到了推动的merge-提交）。merge之前提交diff HEAD shaXX，仅对我写下的那些冲突的文件名 ... merge解决方案之后，已经/已经采取了什么冲突解决方案决定... 但这是很多手动步骤和手动工作，不是很自动化......此外，此方法还意味着显示其中有冲突的文件之间的差异，即将显示 all 差异，我只想查看“ merge conflict解决方案的决定”-我可能会花一些时间来查看数百个不相关的差异，这意味着用这种方法我仍然不清楚，{ {1}}已做出决定（除非我非常小心地写下来，当我尝试自己进行合并时，再次将其按下后）……我的问题是：是否存在更好的（=更多）自动化）方法又如何？