我们公司正在研究现代化我们的版本控制，通常我们想使用git。我之前使用过分布式版本控制，但只使用个人项目和开源项目（有某种用户管理的项目）（Google代码上的Mercurial和LaunchPad上的Bazaar）。如果我们在自己的仓库中使用GIT，我不确定如何验证每个提交的作者。我不是在谈论推送认证，而是提交。GIT作者认证
所以说.. 1.我克隆回购和检查出一个分支。 2.我将我的user.name更改为我的工作人员并进行更改并最终提交。 3.我改变我的用户名和推（例如我的SSH帐户）。 4.我可以把所有的改变归咎于我的同事。
这会成为问题吗？我们如何解决这个问题？
我确定有东西在那里，但我想我不是在寻找正确的信息，所以如果你们可以给我一些基本的概述，这将是非常有益的。
感谢
您不能调节提交的创建，因为这种情况发生在每个用户的工作站上，在资源库中自己的本地副本。
您可以在中央存储库中执行一些检查（使用挂钩），并要求传入提交承载连接用户的名称。 但是，这是一个坏主意。
考虑一个用户可能需要重用其他人的工作，但不想合并它的情况。他可能会挑选别人的承诺，或者将自己的分支重新分配给自己。在这种情况下，正确作者权信息匹配原始提交，并限制传入的提交具有与推送它们的用户相匹配的作者名称会破坏此工作流程。
只有当它成为问题时，我才会担心这一点。这归结为信任：如果你不信任开发者，为什么他们为你工作？
其实这不是我自己的公司，在这里大概有一百人，所以公司基础设施和某些管理人员担心问责制。 – NawaMan 2013-04-10 17:08:35
@NawaMan如果你想要Git的灵活性和敏捷性，那么你就不能强加这个限制。如果贵公司想要集中管理所有内容并施加限制，则不要使用分散式VCS。或者，需要Git推送的代码评论。 – cdhowie 2013-04-10 17:09:52
您可以随时要求用用户的私钥签名提交。但我会说这是全面的。您可以使用服务器端挂钩来确保用户仅限于提交给定名称/电子邮件，但正如cdhowie指出的那样，这使得在某些工作流程中很难提交其他人的工作。 – 2013-04-10 17:34:32
这是一个实际的问题吗？我一直在一家相当大的公司工作，我们使用git进行版本控制，并使用gerrit进行代码评审。从来没有欺骗提交作者/提交者的问题出现。有时候人们做错选择时会误以为自己是作者，但这通常是在代码审查期间被捕获的。 – Michael 2013-04-10 17:02:24
感谢您的回答。现在我们还在评估中，这不是问题。这是剧本中的企业政策和偏执狂。另外，我感到他们不会喜欢我们只能依赖代码审查人员（因为在许多人都在使用的复杂分支的情况下会发生错误）。 – NawaMan 2013-04-10 17:12:35