Git
由于 Git 的分布式特性，一个用户仍然可以使用用户 ABC 进行更改，将其直接推送给用户名为 CBA 的同事，然后该同事将更改推送到中央服务器。
中央服务器无法知道所有这些提交最初是由用户 ABC 还是 CBA 编写的，更不用说推送数据的用户是否是编写代码的用户
这就是服务器维护代码的Pusher的原因。
Git 的解决方案是在分发提交之前使用 GPG 对提交进行签名。只有拥有私钥的用户才能代表自己签署提交。他们也可以签署其他人的更改，基本上表明他们已经审查了代码。您可以签署版本或在执行审核后签署，以确保到那时为止的一致性。超过该点对历史记录的任何更改都会使签名无效。我不建议对每个提交进行签名，因为签名在变基时会被破坏，在压缩合并时可能会丢失。
无法强制作者是 Git 分布式特性的固有特征。
包含一个 Windows 登录脚本来修补中央 git 配置文件以将用户名设置为您想要的用户名是相对容易的，甚至可能比预提交挂钩更容易。只需致电：
$ git config --global user.name "User's Name"
$ git config --global user.email "name@domain"
TFVC
在 TFVC 中，还存在使用 Shelvesets 将代码从一个开发人员移动到另一个开发人员的模型。搁置集可以由一位开发人员创建，由另一位开发人员取消搁置，然后签入中央存储库。这也会将签入的用户注册为作者。不是代码的作者。
原因是TFVC不区分作者和推送者。它假设两者始终相同。在很多情况下，这对于 Git 来说并非如此。
TFVC 签入也不像 git 提交那样可变，但事后可以使用 API 或 Visual Studio UI 轻松更改提交消息。签入笔记也可以。
想想看
任何人都可以对 USB 密钥进行更改，移动到另一台计算机并将更改放入另一个用户的工作区中。您甚至可以通过电子邮件发送，或者在 TFS 中获得正确许可后代表其他人行事。
可能的选择
如前所述，您可以：
- 在 git 中使用预提交挂钩来检测 git 设置中名称/电子邮件的错误配置。
- 通过策略自动设置正确的默认值
- 使用服务器端服务挂钩自动标记包含不匹配的拉取请求（尽管我不会阻止它们，但在中央存储库之外的作者之间共享代码是一个非常强大的协作选项）。
- 使用自定义构建步骤来标记构建期间的可疑更改，并且构建部分成功或完全失败。
- 我怀疑您可以扩展 git 客户端（git 以这种方式非常可配置）以在执行提交时强制执行正确的名称，但这需要您分发自定义 git 配置。
Git 没有内置措施来确保配置的名称与实际用户匹配。但它的影响可能是有限的。只要人们在推送之前审查其他人的更改，Pusher 字段就会反映谁决定实际将这些更改作为主存储库的一部分，而不管代码的编写者是谁。在许多情况下，这是一个更为重要的决定。
如果您现在要做出选择，我的建议是不要使用 TFVC。
