01 · 配置、身份与忽略规则

换电脑、进新公司、提交里突然出现个人邮箱、node_modules 被整目录提交——这类问题都出在配置层，还没开始写业务代码。

配置分三层

Git 读配置时从窄到宽覆盖：仓库本地 > 用户全局 > 系统。同名键以更窄的为准。

范围	参数	文件（常见）	适用
系统	--system	Git 安装目录的 gitconfig	整机所有用户
全局	--global	用户目录 ~/.gitconfig	你这个账号的所有仓库
仓库	--local（默认）	当前仓库 .git/config	仅此项目，例如公司邮箱

git config

作用： 读写 Git 配置。

改动范围： 配置文件。不改工作区、不改历史。

典型场景：

• 新电脑写上名字和邮箱，否则 commit 作者是空的或机器名。
• 公司仓库用公司邮箱，开源仓库用个人邮箱（仓库级覆盖全局）。
• 统一默认分支名、pull 行为、好用的别名。

常用写法：

# 看全部配置以及它们来自哪个文件
git config --list --show-origin

# 只看某一个键
git config --show-origin user.email

# 全局身份（大多数个人项目）
git config --global user.name "Zhang San"
git config --global user.email "zhangsan@example.com"

# 仅当前仓库用公司邮箱
git config --local user.email "zhangsan@company.com"

# 新仓库默认分支叫 main
git config --global init.defaultBranch main

# pull 时用 rebase 而不是生成合并提交（团队要先约定）
git config --global pull.rebase true

# 记住解决过的冲突，同样冲突再出现时复用（多人长期分支很有用）
git config --global rerere.enabled true

# 别名：少打字、少记错参数
git config --global alias.st "status -sb"
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.co switch

不要这样用： 在已经有错误作者的提交上只改 user.email——它只影响之后的 commit，改不了已经写进历史的作者。

做错了怎么办：

# 删掉某个键（例：仓库级邮箱）
git config --unset user.email
git config --global --unset user.email

已经用错邮箱提交了，见 急救手册 · 提交作者错了。

建议先配好的几项

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"    # 或 vim / notepad
git config --global alias.st "status -sb"
git config --global alias.lg "log --oneline --graph --decorate --all"

Windows 上换行符容易和 macOS / Linux 同事打架。团队若没统一，至少先知道：

# 查看当前换行策略
git config --show-origin core.autocrlf

• Windows 常见：core.autocrlf=true（检出 CRLF，提交 LF）。
• macOS / Linux 常见：core.autocrlf=input（提交转 LF，检出不改）。

不要自己在仓库里反复开关 autocrlf 来「修」已经提交的换行。 用 .gitattributes 锁规则，再一次性规范化。见本章末。

凭据（点到为止）

HTTPS 克隆时 Git 会问用户名和 token。现代 Git 一般走 credential helper（Windows 的 Git Credential Manager、macOS 钥匙串）。

• 密码过期、token 失效：去托管平台重新生成 Personal Access Token，再 push 一次，helper 会提示更新。
• 换账号推到别人的仓库：清掉旧凭据，或改用 SSH 密钥，避免 helper 一直用错号。

# 仅查看，不改仓库
git remote -v

凭据本身不是仓库对象，Git 指南帮不了操作系统钥匙串的每一个对话框。推送被拒先看是权限问题还是身份问题，见 07 · 远程同步。

.gitignore：让 Git 假装没看见

作用： 指定哪些尚未跟踪的文件不要出现在 git status / git add 里。

改动范围： 只影响「未跟踪文件是否被看见」。已经 add 或 commit 过的文件，写进 .gitignore 也不会自动消失。

典型场景：

• node_modules/、dist/、.env、IDE 目录、本地覆盖率报告。
• 忽略整个构建目录，但要保留其中某个版本化的文件。

常用写法（.gitignore 文件）：

# 依赖与构建产物
node_modules/
dist/
*.log

# 环境密钥（千万别提交）
.env
.env.local

# 例外：忽略目录里唯独跟踪这个文件
build/*
!build/.gitkeep

规则要点：

• / 结尾表示目录。
• * 通配一段名字；** 跨目录。
• ! 表示不要忽略（前面必须先有更宽的忽略规则）。
• .gitignore 本身通常要提交，这样同事共享同一套忽略。

只对自己生效、不能进仓库的忽略，写在仓库内 .git/info/exclude，或全局：

git config --global core.excludesFile ~/.gitignore_global

不要这样用： 把已经跟踪的 config/prod.json 加进 .gitignore，以为线上密钥就「消失」了。它还在历史里，别人 clone 仍能拿到。

做错了怎么办： 文件已被跟踪，要停止跟踪但保留磁盘文件：

git rm -r --cached node_modules
# 确认 .gitignore 里已有 node_modules/
git commit -m "chore: 停止跟踪 node_modules"

git rm --cached 只从暂存区/索引拿掉，不删工作区。若误加了 --cached 以外的 git rm，文件会被删，见 03 · git rm。

密钥已经 push 出去：当作泄露处理（轮换密钥），不要幻想 gitignore + 再提交能从历史里擦掉。擦历史需要 git filter-repo 并强制所有人重克隆，超出日常范围，见 11 章。

已跟踪文件为什么 ignore 无效

git status 仍显示某个「已忽略」文件时：

# 这个文件现在是什么状态？
git check-ignore -v path/to/file
git ls-files --error-unmatch path/to/file

• ls-files 能列出来 → 它已被跟踪，先 git rm --cached。
• check-ignore 没输出 → 规则没匹配上，检查路径、是否写在子目录的 .gitignore、是否被后面的 ! 规则救回来。

.gitattributes：换行与文件属性

作用： 按路径约定换行、diff 方式、是否当作二进制。比每人本地的 core.autocrlf 更适合团队。

典型场景： 跨 Windows / macOS 合作，PR 里出现「整文件都是换行改动」。

最小可用示例（提交到仓库根目录）：

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

改完属性后如需一次性规范化已有文件，要团队停手协商，不要一个人默默改全仓库换行。本指南不把「全库规范化」当成日常操作。

---

下一章：02 · 创建与克隆仓库