2

我正在研究从颠覆到 git 的迁移。对于初学者，将使用中央存储库方案，就像 svn。

问题是我想确保每个提交都是由真人创建的。

在 subversion 中，假设你没有缓存你的 svn 密码，你可以确定提交作者是真正的作者。

根据我在网上无数次搜索后阅读的内容，我应该在每次推送中央存储库时创建一个签名标签。为了签署标签，我应该检查之前的每一个提交，以确保在我离开计算机时没有人更改任何内容（例如引入恶意代码并稍后将其删除，使其在整体差异中不可见，但是仍在持续构建/测试服务器中执行）。

这意味着我必须仔细检查提交：首先是在我创建每个提交时，然后在我决定使用签名标签推送时再次检查。但这是耗时且多余的。如果签名标签是要走的路，那么我想我应该为每个提交创建一个签名标签。这将用标签填充整个存储库。在我看来，这听起来不太对劲。

我能想到的最干净的解决方案是签署每个提交（自git 1.7.9起支持）。但是由于某种原因我不明白，这样做完全是愚蠢的。由 git 支持，但仍然被认为是愚蠢的。

我应该做些什么？浪费时间仔细检查所有提交并进行每次推送标签签名；或对每个提交进行标记签名；或签署每一个提交？有没有我不知道的替代方案？

提前致谢。

4

2 回答 2

2

我认为你对整个想法真的太过分了，但如果你真的坚持，这里有一个解决方案。

安装Gerrit Code Review作为您的中央 git 服务器。将其配置为禁止来自您不信任的人（可能是您的整个团队，也可能包括您自己）的直接推送。

现在，每个人都将被迫首先提交代码审查。只有受信任的人才能批准更改（同样，这可能只有您）。这些批准将由 Gerrit 服务器记录，只有 Gerrit 可以向前移动分支。

从这一点开始，您唯一信任的 git 存储库是您的 Gerrit 服务器，或者任何其他 git 存储库，对于您关心的所有分支具有完全相同的 sha。

量子点

于 2013-01-12T09:59:26.967 回答
1

如果你信任 Subversion 的密码验证，你也可以信任 git 的密码验证。

您在网上阅读的文章可能适用于开源案例，当使用签名标签在提交之间建立信任链时，即使您不信任托管存储库的服务器。对于 Subversion，不可能不信任 svn 服务器，所以我假设你有一台受信任的机器。在这种情况下，与 svn 相同：保持机器密码安全。Git 不会自己缓存密码，但您可以使用 ssh 公钥有效地允许访问服务器，而无需每次都输入密码。

编辑：我假设您也可以信任您的团队。确实可以以任何人的名义进行提交。但是如果不能信任团队使用他们自己的名字，你也会遇到更大的问题，比如你是否可以信任这些人的实际代码。

于 2013-01-11T11:54:50.203 回答