对于版本控制来说，重要的一件事是知道谁做了什么更改。如果某些内容发生了变化，而我不知道为什么要进行更改，我会查看历史并询问进行更改的人。当我探索 git 时，让我对这个功能有点紧张的一件事是它似乎很容易伪造。是什么阻止我将同事姓名/电子邮件放入 user.name 和 user.email 的 git 全局配置中？当使用像 gitosis/gitolite （它定义了用户）或 github （我假设使用像 gitosis/gitolite 这样的东西）之类的东西时，有什么办法可以看到谁真正做出了提交？
One thing that is important with version control is knowing who made what change. If something was changed and I had no idea why the change was made, I would look in the history and ask the person who made the change. As I am exploring git, one thing that makes me a little nervous about this feature is that it seems really easy to fake. What is stopping me from putting a co-workers name/email in the git global config for user.name and user.email? When using something like gitosis/gitolite (which defined users) or github (which I assume using something like gitosis/gitolite), is there any wyy to see who truly made a commit?
发布评论
评论（3）
Gitolite 会记录每次推送的 Gitolite 用户（在
.gitolite/logs/gitolite-*中）。确定引入特定提交的推送还需要做一些工作，但它应该是直接的（一种方法：在每次推送的尖端放置轻量级标签，然后使用 git name-rev > 查找提交后的第一个标签）。大多数 Gitolite 用户可能只有一个与其关联的 SSH 密钥 (
keydir/user.pub)，但单个用户也可能拥有多个 SSH 密钥 (keydir/user@* .pub）。因此，对于基于 SSH 的 Gitolite，您可以将每次提交映射到一个（或多个）SSH 密钥。
您是否信任 SSH 密钥来准确识别特定人员是另一个问题（即，您是否信任用户会保证其私有 SSH 密钥的安全？）。
Gitolite 还可以通过“智能 HTTP”管理 Git 访问。在这种情况下，Web 服务器会在 REMOTE_USER 环境变量中提供 Gitolite 用户名（即，不使用
.ssh/authorized_keys文件根据 SSH 密钥来识别用户）。识别和身份验证完全取决于 Web 服务器本身（通常只是用户名和密码，但每用户 SSL 证书可用于执行类似于基于 SSH 的访问的操作）。因此，对于基于 HTTP 的 Gitolite，您可以将每次提交映射到由 Web 服务器完成的身份验证。
GitHub 有一些类似的信息，可以通过 事件 部分查询“http://developer.github.com/” rel="nofollow">GitHub API（以前它似乎仅作为您监视的存储库的“Newsfeed”条目的一部分提供）。每个 PushEvent 标识执行推送的 GitHub 用户、引用的名称（分支）已更新，新引用“head”（更新分支的新提示）的名称（SHA1 哈希）以及提交列表。
Gitolite logs (in
.gitolite/logs/gitolite-*) the Gitolite user for each push. There is a bit more work to determine the push that introduced a particular commit, but it should be straight forward (one way: drop light-weight tags at the tip of each push, then usegit name-revto find the first tag after the commit).Most Gitolite users probably only have a single SSH key associated with them (
keydir/user.pub), but it is possible for a single user to have multiple SSH keys (keydir/user@*.pub).So, for SSH-based Gitolite, you can map each commit to one (or more) SSH keys.
Whether you trust an SSH key to accurately identify a particular person is another question (i.e. do you trust the users to keep their private SSH keys secure?).
Gitolite can also moderate Git access over “smart HTTP”. In that case, the web server supplies the Gitolite username in the REMOTE_USER environment variable (i.e. instead of using the
.ssh/authorized_keysfile to identify the user based on the SSH key). The identification and authentication is completely up to the web server itself (usually just a username and password, but per-user SSL certificates could be used to do something more like SSH-based access).So, for HTTP-based Gitolite, you can map each commit to an authentication done by the web server.
GitHub has some similar information and that can be queried through the Events part of the GitHub API (previously it only seemed to be available as part of the “Newsfeed” entries for your watched repositories). Each PushEvent identifies the GitHub user that executed the push, the name of the ref (branch) was updated, the name (SHA1 hash) of the new ref “head” (the new tip of the updated branch), and a list of commits.
据我所知，这不是一个伦理或哲学论坛；这是一个论坛。 但是
git 允许签名提交和签名标签。这应该可以帮助你满足你的偏执:)
This is not a ethics or philosophy forum, afaik; BUT
git allows signed commits and signed tags. This should help you feed your paranoia :)
您可以让每个人都使用 GPG 签署提交：查看本教程。
在本教程中，GPG 密码是在 git config 中设置的，这对我来说似乎毫无意义，因此您需要让钩子在每次提交时提示用户。
当然，如果你不是经理，建议每个人都签署承诺可能会在外交上很困难，所以要谨慎。
编辑：正如布莱恩指出的那样，这只对提交消息进行签名，因此这不是一个好的解决方案。我保留答案，因为它可能仍然有助于理解问题。
You can have everybody sign commits with GPG: see this tutorial.
In the tutorial the GPG passphrase is set in git config, which seems nonsense to me, so you'll want to have the hook prompt the user at each commit.
Of course if you're not the manager, proposing that everyone sign their commits can be diplomatically tough, so be prudent.
EDIT: As Brian points out, this only signs the commit message, so it's not the good solution. I keep the answer as it might still help to understand the problem.