dotfiles 管理:换机器十分钟恢复工作环境
换一台机器,第一天的效率基本为零:快捷键不对、补全没有、别名全忘。
dotfiles 仓库能把这个恢复时间压到十分钟以内。
先说结论
配置进 git、用 stow 建软链、机器差异用 include 分离、密钥绝不入库。
- 仓库按工具分目录(zsh/nvim/tmux)
- stow 建软链,避免复制导致两份不同步
- 机器专属配置放 local 文件并 gitignore
- 敏感信息用环境变量或密钥管理
先把问题说清楚
dotfiles 的核心矛盾是「通用」与「机器差异」。解决办法是分层:通用配置入库,机器差异放本地文件。
软链接优于复制:改配置就是改仓库文件,提交即可。
具体怎么做
按顺序执行,每步都验证完再进下一步:
- 建仓库,按工具建子目录
- 把现有配置移进仓库,用 stow 建软链
- 抽出机器差异到 ~/.zshrc.local,并在主配置里 source
- 写 install.sh:装包、建链、装插件
- 在 CI 或新机器上跑一次验证
参数与成本对照
把关键数值摊开,方便判断该选哪条路:
| 方式 | 优点 | 缺点 |
|---|---|---|
| 软链接(stow) | 改一处即生效 | Windows 需额外工具 |
| 复制脚本 | 简单 | 两份易不同步 |
| 配置管理工具 | 适合多机 | 学习成本高 |

几个容易踩的坑
下面这些是最常见的错误做法:
- 把 SSH 私钥、token 提交进仓库
- 机器差异写死在主配置里:换机器就报错
- 只备份不验证:装完发现插件没装
- 软链指向已删除的文件:shell 启动报错
最后补两句
dotfiles 是给自己用的,不必追求「大而全」,够用、能装、可复现就行。
工具是手段,理解机制才是能力。命令记不住没关系,知道「该看什么」就够了。
评论 (3)
照着做了一遍,确实少走弯路。第二步最容易漏,建议顺手加个检查清单。
比「一键脚本」有用多了,知道为什么比知道怎么做重要。
补充一句:不同版本行为会变,动手前先确认自己的版本号。
发表评论