Git 修改全局用户名/邮箱后，为何新提交仍显示旧信息？

Question

Git 修改全局用户名/邮箱后新提交仍显示旧信息，常见原因有三：一是本地仓库已存在 `user.name` 和 `user.email` 的**仓库级配置**（`.git/config` 中的 `[user]`），其优先级高于全局配置（`~/.gitconfig`），会覆盖全局设置；二是执行 `git config --global` 命令时未生效（如拼写错误、权限不足或配置文件路径异常）；三是当前操作不在 Git 仓库根目录下，导致命令作用于错误上下文。此外，若此前已用旧信息提交过，历史提交记录不可变，仅后续新提交受新配置影响——但若新提交仍显示旧信息，必然是当前仓库的本地配置未更新。验证方式：在仓库内运行 `git config user.name` 和 `git config user.email`（不加 `--global`），即可确认实际生效的配置来源。解决只需在目标仓库中执行 `git config user.name "New Name"` 和 `git config user.email "[e-mail]"` 覆盖本地设置即可。

Answer 1

```html

一、现象层：为什么“改了全局配置，提交却还是旧名字？”

这是 Git 使用者（尤其跨团队、多身份开发者）高频遭遇的“幻觉型问题”——明明执行了 git config --global user.name "Alice" 和 git config --global user.email "[e-mail]"，但 git commit 后 git log 仍显示旧邮箱与姓名。表面看是配置失效，实则是 Git 配置层级机制在静默生效。

二、机制层：Git 配置的三级优先级模型

Git 遵循明确的配置作用域优先级（由高到低）：

1. 仓库级（local）：位于 .git/config，仅对当前仓库生效，最高优先级；
2. 全局级（global）：通常为 ~/.gitconfig（Windows 下可能是 %USERPROFILE%\.gitconfig），影响用户所有仓库；
3. 系统级（system）：如 /etc/gitconfig（Linux/macOS），需 root 权限，极少手动修改。

关键结论：本地配置永远覆盖全局配置——哪怕你已正确设置全局项，只要 .git/config 中存在 [user] 区块，它就会被无条件采用。

三、诊断层：精准定位配置来源的四步验证法

命令	含义	典型输出示例
git config user.name	查询当前仓库生效的 name（含 local > global 层级）	Old Dev
git config --global user.name	仅查全局配置值	Alice
git config --list --show-origin	列出所有配置项及其来源文件路径	file:.git/config user.name=Old Dev
ls -la .git/config	确认本地配置文件是否存在且可读	-rw-r--r-- 1 user staff 248 ...

四、根因层：三大典型失效场景深度剖析

• 场景①：本地配置残留劫持——克隆自他人仓库、CI 模板初始化或早期手动配置未清理，导致 .git/config 中固化了 [user] 段落；
• 场景②：全局配置“伪成功”——执行 git config --gloabal（拼写错误）、用 sudo git config --global 写入 root 用户配置、或 HOME 环境变量异常导致 ~/.gitconfig 实际写入失败路径；
• 场景③：上下文迷失——在子目录（如 project/src/）而非仓库根目录执行 git config --global，虽不报错，但误以为操作的是本地配置，实则仍在改全局。

五、解决层：安全、可追溯的修复流程

推荐按顺序执行以下操作（适用于单仓库修复）：

# 1. 进入仓库根目录（确保 pwd 输出含 .git）
cd /path/to/your/repo

# 2. 查看当前生效配置（关键！）
git config user.name
git config user.email

# 3. 覆盖本地配置（非 --global！）
git config user.name "New Name"
git config user.email "[e-mail]"

# 4. 验证结果（应返回新值）
git config user.name  # → "New Name"
git config user.email # → "[e-mail]"

六、进阶层：批量治理与工程化预防

对于多仓库开发者或团队基建，建议建立如下实践：

• 使用 git config --unset user.name + --unset user.email 清理本地配置，强制回退至全局；
• 编写 shell 函数 git-set-identity() { cd "$1" && git config user.name "$2" && git config user.email "$3"; } 提升复用性；
• 在 CI/CD 流水线中注入 git config --global user.name "${GIT_AUTHOR_NAME}" 等动态变量，避免硬编码；
• 启用 git config --global init.defaultBranch main 等配套规范，构建一致性环境。

七、认知层：不可变提交的本质与配置边界

必须强调：Git 的历史提交（commit object）是 SHA-1（或 SHA-256）哈希锁定的，其 author/committer 信息一旦写入即永久不可修改（除非重写历史，如 git rebase -i 或 filter-repo）。因此，“修改配置只影响后续提交”不是 Bug，而是 Git 设计哲学的体现——配置控制的是“未来签名”，而非“过去凭证”。这也是为何验证必须聚焦于 下一次 commit 的 author 字段，而非试图修正 git log 中已存在的旧记录。

八、可视化层：配置解析决策流

graph TD
  A[执行 git commit] --> B{是否定义 local user.name/email?}
  B -->|Yes| C[读取 .git/config 中 [user] 值]
  B -->|No| D{是否定义 global user.name/email?}
  D -->|Yes| E[读取 ~/.gitconfig 值]
  D -->|No| F[报错：please tell me who you are]
  C --> G[使用该值生成 commit author]
  E --> G

```