我很困惑地看到我的同事Alice在git日志中进行了合并提交，而Bob向我保证确实是他进行了合并。我看不到Bob的其他合并提交，因此看起来Alice设法以某种方式接管了Bob的提交。
爱丽丝确实确实也做了一些事情，但是她的提交活动很可能是在鲍勃之后。爱丽丝通过Visual Studio的git ui专门使用git。
我知道可以通过rebase操作重写本地提交，但是据我了解，对于已推送的提交，通常不执行此操作。我认为图形化git ui不会做任何异常的事情。
那么，为什么我在git日志中看到Alice是作者和提交者？可能是什么原因导致的？
编辑：其他提交都有明智的作者，因此这不仅仅是配置错误的用户名。
答案 0 :(得分：0)
每个提交对象都包含两个字段。您可以使用命令行git cat-file -p操作检查原始提交对象。例如：
$ git cat-file -p 83232e38648b51abbcbdb56c94632b6906cc85a6 | sed 's/@/ /'
tree 894962f72d565687c409f018060fdefa20e5f3fe
parent aa8c8d914e4ae709e4fd025f359594f62653d9e5
author Junio C Hamano <gitster pobox.com> 1556175832 +0900
committer Junio C Hamano <gitster pobox.com> 1556178085 +0900
The seventh batch
Signed-off-by: Junio C Hamano <gitster pobox.com>
一旦提交，就不能更改：提交的哈希ID，在这种情况下为83232e38648b51abbcbdb56c94632b6906cc85a6，是提交的内容的加密校验和。如果我使用此文本，更改名称并从结果中进行新的提交，则会得到一个不同的提交哈希ID。
现在，我可以这样做，然后，我可以将所有直接下游提交（83232e38648b51abbcbdb56c94632b6906cc85a6的所有子级）复制到具有我的新提交和不同提交中新提交作为其父项。然后，我必须复制那些提交者的孩子，以及他们的孩子的孩子，依此类推，所有这些都是为了使您相信我的83232e38648b51abbcbdb56c94632b6906cc85a6副本是您应该复制的副本。采用。如果在此复制的链中有任何 signed 提交或签名的带注释的标签，除非拥有Junio Hamano的签名密钥，否则我将无法正确对其进行签名。因此，您也许可以说出我是这样做的-即使没有任何签名密钥，您也仍然可以知道，因为我提供给您的Git存储库以及这些复制后的替代品不匹配您先前选择的副本，其中包含原稿。
因此，合并上有爱丽丝名字的事实（假设您的GUI不在您面前）意味着合并上有爱丽丝名字。这并不意味着Alice实际上已经做到了，因为Bob可以将自己的Git设置为声称在Bob进行合并期间是Alice。如果要验证谁进行了提交，则还需要在提交或带注释的标签上进行某种数字签名。 （对每个提交进行签名是一件很痛苦的事情，这就是为什么Git开发人员仅对他们带注释的标签进行签名的原因。）
为什么以及如何发生这种情况我们无法猜测。鲍勃（Bob）说自己不是恶作剧时，是否相信，这取决于您。您必须观察实际发生的情况并从那里进行调查。