外观
用版本库管理 dotfiles：让配置能重建、能回滚
改了几个月终端配置之后，你会遇到两个问题：新机器要从头再配一遍，以及某次改动之后出了问题却不知道改了什么。两个问题的答案是同一个——把配置文件放进版本库。
「dotfiles」指的是主目录下以点开头的配置文件，例如 .zshrc、.gitconfig。点开头在 Unix 惯例里表示默认不显示，ls -a 才能看到。
开始之前
需要会用 Git 的基本操作（init、add、commit）。需要先知道自己有哪些配置文件在起作用，见zsh 启动文件与加载顺序——把不起作用的文件纳入版本库，只会制造混乱。
先看一眼主目录里有什么：
sh
ls -a ~ | head -30ls -a 列出包括隐藏文件在内的全部内容，~ 是主目录，head -30 只取前 30 行避免刷屏。你会看到几十个点文件和点目录，其中大部分是软件自动生成的缓存，不需要纳入版本库。
先决定哪些进、哪些不进
这一步比选工具重要得多。
值得纳入的：你亲手编辑过、并且换台机器还想要的文件。典型的是 .zshrc、.gitconfig、.config/ 下你自己写的配置、编辑器配置。
绝对不要纳入的：任何包含密钥、令牌、密码的文件。.ssh/id_* 是私钥，.aws/credentials、.npmrc、.netrc 经常含令牌。这些文件一旦推送到公开仓库，即使随后删除提交，也必须视为已泄露并立即更换凭据。
不必纳入的：缓存目录（.cache）、软件自动生成的状态（.zsh_history、.DS_Store）、由包管理器重建的内容（node_modules）。
个人信息也要想一想：.gitconfig 里通常有你的邮箱。放进公开仓库等于公开它，见写作规范中的公开边界里关于哪些信息值得保护的说明。
三种做法，按复杂度排列
一、符号链接 + 一个普通仓库
最容易理解：建一个 ~/dotfiles 仓库，把真实文件放进去，再在原位置建符号链接指向它。
sh
mkdir -p ~/dotfiles && cd ~/dotfiles && git init
mv ~/.zshrc ~/dotfiles/zshrc
ln -s ~/dotfiles/zshrc ~/.zshrcmkdir -p 创建目录（-p 表示父目录不存在时一并创建），mv 把原文件移进仓库，ln -s 建立符号链接——第一个路径是真实文件，第二个是链接位置。之后编辑 ~/.zshrc 实际改的是仓库里的文件。
验证链接正确：ls -l ~/.zshrc 应当显示 -> /Users/你的用户名/dotfiles/zshrc。出错的退路：rm ~/.zshrc && cp ~/dotfiles/zshrc ~/.zshrc，删掉链接、复制回真实文件即可恢复原状。
二、GNU Stow
brew install stow 之后，把仓库按目标结构组织，stow 负责批量建链接。省去手工 ln，代价是要理解它的目录约定。文件多了之后比第一种省事。
三、chezmoi
brew install chezmoi。它不用符号链接，而是从仓库「生成」目标文件，因此支持模板——同一份配置在不同机器上产出不同内容（比如工作机和个人机用不同的 Git 邮箱），还内置了密钥管理器集成。
怎么选：只有几个文件、只有一台机器，用第一种，你能完全看懂发生了什么。多台机器、需要按机器区分配置，再考虑 chezmoi。不要因为教程流行就直接上最复杂的方案。
在新机器上重建
仓库的价值在这一步兑现。新机器上：
sh
git clone <你的仓库地址> ~/dotfiles然后按你选的方案建立链接。配合Brewfile 包清单一起用，软件和配置就能一起重建。
第一次重建一定会发现遗漏——某个配置没纳入、某个工具没记录。把遗漏补进仓库，这比一次就做对更现实。
检查结果
在仓库里 git status 应当是干净的；修改 ~/.zshrc 之后再看，应当显示仓库里对应文件被修改——这证明链接生效了。
打开一个新终端窗口确认配置仍然正常加载。然后做一次真正的回滚演练：git checkout -- zshrc 撤销未提交的改动，开新窗口确认恢复原样。能回滚，版本库才算发挥作用。
动手练习
只纳入一个文件，走完整个流程：
- 把
.gitconfig移进~/dotfiles并建立符号链接。 git add并提交，提交信息写清楚这次纳入了什么。- 改一处配置（例如增加一个别名），提交。
- 用
git revert撤销这次提交，开新终端确认别名消失。 - 检查提交里有没有邮箱之类你不想公开的内容；有就先不要推送到公开仓库。
成功标准是走完第 4 步，配置确实回到了改动前。第 5 步不要跳过——dotfiles 仓库泄露密钥是很常见的事故，而公开仓库的历史记录删不干净。