Git在合并后显示错误的作者

Question

我很困惑地看到我的同事 Alice 在 git 日志中的合并提交，并且 Bob 向我保证确实是他进行了合并。我没有看到 Bob 的其他合并提交，所以看起来 Alice 以某种方式设法接管了 Bob 的提交。

Alice 确实也提交了一些东西，但她的提交活动可能发生在 Bob 之后。 Alice 仅通过 Visual Studio 的 git ui 使用 git。

我知道本地提交可以通过 rebase 操作重写，但据我了解，对于已经推送的提交，通常不会这样做。我会假设图形化的 git ui 不会做任何不寻常的事情。

那么为什么我在 git 日志中看到 Alice 是作者和提交者呢？可能是什么原因导致了这种情况？

编辑：其他提交有明智的作者，所以这不仅仅是配置了错误的用户名。

Answer 1

每个提交对象都包含两个字段，作者和提交者。您可以使用命令行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 副本是你应该使用的副本。如果在这个复制的链中存在任何 已签名 提交或已签名注释标签，除非我拥有 Junio Hamano 的签名密钥，否则我将无法正确签署它们。所以你可能会说我做了这个——即使没有任何签名密钥，你可能仍然可以说出来，因为我提供给你的 Git 存储库，以及这些复制的替换，将不匹配你之前拿到的副本，里面有原件。

因此，合并包含 Alice 的名字这一事实（假设您的 GUI 没有对您撒谎）意味着该合并包含 Alice 的名字。这并不意味着 Alice 实际上 成功了，因为 Bob 可以将他的 Git 设置为在 Bob 进行合并期间声称自己是 Alice。如果您想验证提交的人，您还需要某种数字签名，无论是在提交上还是在带注释的标签上。 （每次提交都签名很痛苦，这就是为什么 Git 开发人员只签名他们的注释标签。）

我们无法猜测为什么以及如何发生这种情况。当 Bob 说他不是恶作剧时，是否相信他取决于你。您必须观察它的实际发生情况并从那里进行调查。