在解决git中的合并冲突更改并提交后，它使用另一个用户作为作者

我的本地用户是用户A，我在另一个分支中选择提交。提交作者是用户B。当我（作为用户A）遇到一些冲突时，我（用户A）解决这些冲突并在本地提交。但是提交历史记录显示提交作者是用户B。我无法想象这一点。如果没有cherry Pick（本地更改提交），它可以正常工作。

git

在每次提交时存储一个作者名和一个提交者名。如果运行创建新提交对象的命令，则本地设置应指示提交者

但一般来说，当命令复制另一个提交时，作者也会从另一个提交复制（未更改）（正如您应该预料的那样；仅仅因为您选择了一个提交并不意味着您编写了它引入的更改）

特别是对于rebase或cherry pick，一次提交可能会引入多个作者的更改，然后git仍然需要识别一个作者。在本例中，有被复制的原始内容的作者，以及任何冲突解决方案的作者。git认为冲突解决相对较小似乎是合理的。所以，虽然你无法想象它会以这种方式工作，但我无法想象它会将承诺的潜在变化重新归功于仅仅重新承诺的人

在使用

squash

命令的交互式重基的情况下，元数据似乎取自操作中涉及的早期提交。对我来说，这似乎是一个更令人震惊的假设，但我想这是一个想法，您可能正在组合一组相关的更改（即，常见情况可能是单个用户在共享之前崩溃本地分支），如果您需要跟踪谁在何时做了哪些更改，那么您就不会挤压提交

另一方面，

merge

命令的

--squash

选项将生成的提交视为运行

--squash

命令的人新编写的提交（更像您期望的行为），但默认情况下，它会在新提交的消息中保留每个原始提交的作者身份

---

因此，综上所述，要点是：不要把作者元数据看得太重。如果您需要提示“某某可能知道一些关于此代码的信息”，那么这是一个很好的工具；这不是一种100%可靠的方法来为完成的工作分配积分，当然也不是谁做了什么的“证据”（即，如果你需要一种方法来审计，在用户a签署了变更X之后，那么你需要其他东西，比如签名）.

次要添加：为了查看提交示例的提交者/作者信息，您可以使用例如：

git log-1--pretty=“格式：%h，作者：%an，提交者：%cn”ada4440

或

git cat file-p ada4440

@JayaniSumudini-如果你不能通过使用作者信息来责怪某人的问题，那么我想不要使用将多个作者的更改混合到一个提交中的命令。