当本地电子邮件配置和github中的电子邮件设置不匹配时,为什么github协作者仍然可以推送到私有仓库?

时间:2020-10-23 13:08:55

标签: git github version-control

对于仅向协作者开放的私有存储库,我发现即使是一个协作者也不会在github中使用他的电子邮件设置,如果他将存储库克隆到本地,那么他仍然可以将某些内容推送到存储库中。

Git日志显示类似Author: username <user@MacBook-Pro.local>的内容,并且在提交消息中,图形表达为灰色。我知道这表明本地和github电子邮件之间不匹配: Why are my commits linked to the wrong user?

但是,在访问设置中,仅对Github中的电子邮件设置开放访问。这样的推送如何完成?这是否意味着任何带有邀请电子邮件的计算机都可以将某些内容推送到存储库中,换句话说,访问权限不仅限于唯一的电子邮件吗?如果这是真的,我认为这对回购来说是危险的。

我试图搜索“ git local repo和远程单站之间的链接是如何工作的”之类的问题,但是大多数结果只是用于建立连接的简单教程,而没有揭示更深层的机制。

2 个答案:

答案 0 :(得分:2)

有两个独立的身份:

  1. 提交的作者和编辑(提交者)
  2. 用于与GitHub通信的凭据

第一个记录在您的提交历史中,当有人在其计算机上创建新提交时,取自git配置中的user.nameuser.email

第二个由推送https时提供的登录名或推送ssh时的ssh键表示。


如果您推送(例如:使用ssh键)由其他人创建的提交,则推送成功,但是该提交已链接到“其他人”。


您是否有理由相信 push 是由被撤消的用户执行的?

如果是这样,则表示他仍然可以访问允许他按下的登录名/密码或ssh密钥;您可以通过更改密码或取消隐含的ssh密钥并生成一个新的ssh密钥来解决此问题。

否则:检查git历史记录,然后确定是否应编辑某些提交的“作者”字段即可。
请注意,默认情况下,诸如git rebasegit cherry-pickgit commit --amend之类的操作会保留原始作者。

答案 1 :(得分:1)

正如LeGEC所说,这里有两件事。

首先,提交具有作者和提交者,并且每个身份都有一个名称(通常是个人名称,而不是用户名)和电子邮件。 GitHub根据与他们的帐户匹配的电子邮件将提交与用户相关联。如果提交电子邮件与任何帐户都不匹配,您将获得一个通用头像。

第二,当您推送提交时,存储库上会进行某种身份验证,对于GitHub,参与者将成为用户,某种集成或bot或部署密钥。

请注意,这些不相关。如果您具有对存储库的推送访问权限,则可以使用任何(格式正确的)名称和电子邮件从任何用户推送提交。这很重要,因为在某些项目(例如Git本身)中,提交是由维护人员收集的,然后将其推送到主存储库。其中一些贡献者可能没有GitHub帐户,并且仍然需要进行推送。

最可能的答案是您的贡献者未正确配置(或未配置)其Git设置,因此正在使用链接到本地​​计算机的电子邮件地址创建提交,然后他们使用其有效凭据进行推送。

如果是这样,您应该与您的贡献者交谈,并告诉他们将user.name设置为其个人(人名),并将user.email设置为与其GitHub帐户相关联的有效电子邮件。 GitHub提供了无法传递的地址,如果他们不想公开真实的电子邮件,可以在设置中找到。

请注意,user.name has no effect on authentication通常不是用户名。