3

对我来说，手动解决的冲突是最大的错误来源之一。

目前我们正在解决在一台显示器前大声聚集的冲突，我认为这是石器时代的做法。此外，在保存并关闭视觉差异工具后，如果我们想复查或修复某些问题，我们以后无法返回冲突视图。

我正在寻找一种方法来快速查看 git 中所有最新的手动解决的冲突。

我希望看到每个冲突的 A 分支、B 分支和生成的代码段。

我可以手动为 deside 工具提供提交编号，或者我可以在列表中查看冲突。

无关：

如果发生冲突，我的好主意是引入合并审查。所有负责该部分代码（在两个分支中）的开发人员都应该审查冲突，尤其是在他们远程工作时。只有在双方确认后才允许合并怎么办？

4

3 回答 3

2

使用 git 很容易：

git log --patch -c -1 YOURMERGE

这将输出如下内容：

index ea575f9,b943345..239a586
--- a/file-with-conflicts.txt
+++ b/file-with-conflicts.txt
@@@ -1,1 -1,1 +1,1 @@@
- Version A
 -Version B
++Merge Resolution
于 2013-01-24T23:21:38.233 回答
2

我觉得这些“大喊大叫的比赛”也许可以通过改变工作流程来避免。假设开发人员正在开发一个主题分支，但他落后于master.

A--B--C--D--E--F
       \
        X--Y--Z

而不是他或小组提出合并提交，他可以将他的更改重新定位到他的本地master

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

然后，当时机成熟时，它将允许对“官方”主服务器进行干净的合并提交

A--B--C--D--E--F--X'--Y'--Z'

参考

于 2013-01-24T16:19:26.067 回答
0

从git help log页面：

git log --patch -c -1 <commit-id>

-c 使用此选项，合并提交的差异输出同时显示每个父级与合并结果的差异，而不是一次显示父级与结果之间的成对差异。此外，它仅列出从所有父项修改的文件。

-p, -u, --patch 生成补丁（参见生成补丁部分）。

于 2015-09-01T15:52:59.523 回答