究竟是什么决定了提交上的邮箱
提交的作者邮箱由创建该提交的机器上的 Git 配置决定，而不是由你 GitHub 个人资料上显示的邮箱决定。你的 GitHub 个人资料邮箱是一个独立设置，用于通知、账户恢复以及某些网页界面操作。如果你从终端提交，写入提交对象的地址来自你本地的 user.email 值。这一区分就是关键：更改个人资料邮箱对未来的命令行提交毫无影响，而更改本地 Git 配置对已经推送的提交也毫无影响。
Git 配置控制的是从命令行创建的后续提交所附带的邮箱。来源
在更改任何内容之前，先理解你正在审计什么。你并不是要试图从 GitHub 上抹去你的邮箱。你要决定的是：从现在起你创建的提交上应该出现哪个地址，以及你的任何仓库是否仍依赖旧地址来进行归属标识或工具集成。
第 1 步：检查你当前提交所携带的身份
首先查看你最近的提交实际包含什么。在你拥有的仓库中，运行一个日志命令，显示最近几次提交的作者和提交者邮箱字段。目标是看到确切的地址字符串，而不是判断它是否敏感。在你从命令行推送的每个仓库中都这样做，因为本地配置可能因仓库而异。
接下来，检查 Git 在该仓库中将使用的有效配置。Git 从多个作用域解析配置，仓库级的值会覆盖全局值。如果你看到不认识的地址，它可能来自仓库本地设置、被包含的配置文件，或你 shell 中的环境变量。在编辑前记录你的发现；无法复现的审计不算审计。
第 2 步：在头脑中区分这两个设置
使用下面的决策表，将个人资料设置与提交设置区分开。它描述的是你可以在自己账户和终端中验证的一般机制；它并不断言具体的菜单标签或当前 UI 路径。
| 问题 | 由什么控制 | 更改它会影响什么 | 它不会影响什么 |
|---|---|---|---|
| 我的 GitHub 个人资料上显示哪个邮箱？ | GitHub 账户邮箱设置 | 个人资料显示、通知、账户恢复 | 你在本地创建的提交上的作者邮箱 |
| 新提交中写入哪个邮箱？ | 本地 Git user.email 配置 | 从该机器或仓库创建的后续提交 | 已经创建或推送的提交 |
| 如果我切换到 noreply，旧提交会改变吗？ | 不会自动改变 | 无 | 现有提交对象保留其原始作者邮箱 |
| 我能对未来公开提交隐藏我的邮箱吗？ | 本地 Git 配置加上 noreply 地址 | 更改后你创作的新提交 | 过去的历史、复刻以及别处的缓存副本 |
这张表的实际要点：你有两个独立的杠杆。如果你担心的是未来的推送，就拉动提交这个杠杆。不要指望个人资料杠杆来完成这项工作。
第 3 步：选择一个 noreply 地址并在本地配置
GitHub 提供 noreply 地址选项。确切格式由 GitHub 文档说明，并且可能随时间变化，因此请从你自己的账户设置中复制该地址，而不是从博客文章中复制。拿到地址后，在与你的工作流匹配的作用域中将其设置为提交邮箱。
一个安全的顺序：
- 从你的账户设置中复制 GitHub 提供的 noreply 地址。
- 决定作用域：如果机器上的每个仓库都应使用它，则全局设置；如果你参与的项目期望不同的身份，则按仓库设置。
- 使用
git config在所选作用域应用该设置。 - 在一个临时分支上创建一个测试提交，并在推送前检查其作者邮箱。
- 只有在测试提交显示 noreply 地址后才推送。
GitHub 提供 noreply 地址选项；更改已配置的地址不会重写现有提交。来源
第二点正是人们容易忽略的。切换到 noreply 是一种前瞻性控制。它不会重写现有提交，也不会从已经公开的提交对象中移除你的旧地址。如果一个仓库已被复刻或镜像，无论你今天配置什么，那些副本都会保留原始提交数据。
第 4 步：单独检查网页界面和工具的行为
通过 GitHub 网页界面创建的提交，或由机器人和集成创建的提交，可能使用与本地终端不同的身份路径。不要假设本地配置更改能覆盖进入仓库的每一个提交。检查来自不同来源的提交的作者字段，并注意哪些是你直接控制的。对于你无法控制的集成，诚实的答案是：你无法从自己的笔记本电脑上设置它们的提交身份；你只能决定是否继续使用该集成。
第 5 步：决定如何处理旧历史
你有三个现实的选择，但没有一个是“让旧的暴露消失”。
| 选项 | 它做什么 | 代价与限制 |
|---|---|---|
| 保持历史原样 | 没有破坏克隆或引用的风险 | 旧提交保留原始作者邮箱 |
| 在你自己的仓库中重写历史 | 在该仓库中改变后续的提交对象 | 重写具有破坏性，无法触及复刻或镜像，且超出大多数用户的范围 |
| 移除或轮换已暴露的地址 | 如果地址仍活跃，可减少未来暴露 | 不会改变已经包含它的提交 |
对大多数读者来说，正确的做法是第一个或第三个：停止将地址添加到新提交中，并将旧提交视为永久公开。如果暴露的地址仍用于登录或恢复，考虑它是否还应与账户关联。这是账户安全决策，而不是 Git 配置决策。
常见错误
- 更改个人资料邮箱并假设提交已修复。 个人资料设置和提交身份是分开的。在你更改本地 Git 配置之前，未来的终端提交仍会携带旧地址。
- 全局设置 noreply 而不检查仓库覆盖。 仓库本地的
user.email会覆盖你的全局值。审计你推送的每个仓库。 - 将测试提交推送到公共分支。 在推送前，在临时分支上或通过本地日志验证作者邮箱。
- 相信 noreply 切换能清除历史。 它不会重写现有提交，也无法触及复刻、镜像或缓存副本。
- 假设每个提交来源都在你的控制之下。 网页界面提交和集成提交可能使用不同的身份；检查它们，而不是假设。
- 将编辑个人资料视为删除。 更改个人资料显示的内容不会删除存储的数据或改变提交对象。
保护你自己的数字足迹
提交邮箱只是一个狭窄的渠道。你的公开足迹还包括与其他平台上该地址关联的用户名和个人资料。如果你因为某个地址出现在公开场合而审计它，有用的下一步是查看哪些公开账户与该地址关联。TruthsSeek 关于如何查找与电子邮件地址关联的账户的指南介绍了这一审查过程，而 /find/github/ 上的 GitHub 查询页面是检查已知用户名的起点。TruthsSeek 所介绍的 TraceSeek 应用可在 3,000+ 个平台上检查用户名，并提供免费首次扫描；产品声明扫描需要 20–30 秒。这些工具将公开匹配作为线索呈现，而非所有权证明，它们不会更改平台设置或暴露私人记录。用它们来梳理已经公开的信息，然后在平台上进行配置更改。
一个现实的例行程序：一次性修复你的本地 Git 身份，用测试提交验证它，然后定期重新检查来自新工具或机器的提交的作者字段。将每一个已推送的提交视为永久的公开数据，因为实践中通常如此。
关键事实
- Git 配置控制的是从命令行创建的后续提交所附带的邮箱。
- GitHub 提供 noreply 地址选项；更改已配置的地址不会重写现有提交。
- GitHub 个人资料邮箱设置和本地 Git 提交邮箱设置是独立的控制项，效果不同。
- TraceSeek 在 3,000+ 个平台上检查用户名，并提供免费首次扫描，产品声明的扫描时间为 20–30 秒。
- 公开用户名匹配是线索，而非账户所有权证明。