我们经常遇到用户问题＆＃34;错误＆＃34;修复git合并冲突和破坏事物。
我是否遗漏了任何git log个参数，我可以用它来查找最近出现冲突的合并，以及哪个git用户解决了所述冲突。
在某些情况下，这是有人将主人合并到＆＃34;测试＆＃34;分支，所以它可能包含许多人的工作。
工作流： -
git工作流程需要改进很多并且要求更严格，但是我能做些什么来在短期内找到错误修复合并冲突的用户吗？
答案 0 :(得分：2)
从某种意义上说，这真的是微不足道的。换句话说，这很难。
这是多么微不足道的事情：
这是非常困难的：
没有自动方法可以找到该问题的答案。
如果您有良好的自动化测试，您可以随意接近自动回答问题。良好的自动化测试并不容易，如果你想让它们变得非常好，就会变得非常困难。
如果你没有自动化测试，但确实有一些擅长正确合并的人，你可以做点抽查：只需让这些好人自己重复合并，并将他们的结果与之前的比较结果。如果相同，则原始合并正确完成。如果不同，则不是。
合并冲突的存在与否不是关于合并是否正确完成的确定指标。 Git没有秘密知识：它只是根据一组固定的规则组合文本。也就是说，如果您希望选择，对于手动测试，特别是那些 看到冲突的合并，您可以自动执行此部分。只需重复合并（确保未启用git rerere）并查看是否存在冲突。
上面，短语“重复合并”出现两次。您可能想知道如何重复合并。这主要是微不足道的。 2 首先，找到每个合并的提交ID：
git rev-list --merges <start-point> [additional options if desired]
这会生成一个候选ID列表。 （你会希望将它们保存在某个地方，并注释你检查了哪些，这样你以后就不必重新检查它们。使用你喜欢的任何临时解决方案。）
然后，给定一个合并ID，只需将其第一个父项作为分离的HEAD检出，并对其余的父ID运行git merge（此位依赖于POSIX shell行为和语法）：
id=c79a113... # or whatever, from your list
set -- $(git rev-parse ${id}^@)
git checkout $1 # check out first parent
shift # now that we have $1 out, discard $1
git merge $* # (attempt to) merge the remaining commits
rev^@符号来自gitrevisions，表示“给定修订版的所有父母”。如果所有合并都是标准的双父合并，则可以使用更清晰的（但不太通用）：
git checkout ${id}^1
git merge ${id}^2
（gitrevisions语法和shell set和shift技术允许章鱼合并。）
由于此合并是在分离的HEAD上进行的，因此生成的合并（如果它自动完成）可以通过检出任何其他提交或分支名称来轻易放弃。如果git merge因冲突而失败，则会出现冲突的合并，并且通常会在索引中生成结果;您可以继续完成合并，或使用git merge --abort来终止合并。 （如果合并成功，则git merge的退出状态为0，否则为非零。）
1 请记住，除了通过推送或提取进行提交传输之外，每个Git操作都由本地由完全控制其自己的存储库的人完成。用户当然可以说谎并声称自己是别人。如果您完全控制了这一点，您可以而且必须在传输边界执行此操作：当您从其他人那里获取提交时 - 无论是来自您的git fetch，还是来自他们的git push知道你正在和谁谈话（通过你所做的任何身份验证：这完全在Git之外，现在通常来自ssh或https，通常包含在像Gitolite这样的第三方扩展中，或者由GitHub等提供的服务。在接受提交之前，您现在有机会做任何您喜欢的验证。
或者，您可以使用例如PGP签名检查“事后”。如果有人对PGP签名了一些标记和/或某些提交，并且您可以验证这些签名，则可以选择相信这些标记和/或提交是他们的。然后，您可以将这种信任（当然，基于SHA-1的安全性和您对信任者的信任程度）扩展到那些提交'和/或标记'祖先，因为构建匹配的对象预定义的SHA-1及其文本至少非常难。 （这称为第二个前映像电阻;请参阅，例如this crypto.stackexchange.com question。）
2 我说“大部分都是微不足道的”，因为用户提供给git merge 的选项在这里不可用。您可以要求使用非标准合并选项的用户在提交中或在提交附加的注释中记录它们，但这很难实施。另请参见脚注1：您只能在转移边界应用强制执行规则。