哪些 Dotfiles 应该提交到 Git(哪些应该忽略)

在多台机器之间管理 dotfiles 是开发者常见的难题。你花费数小时完善了 shell 配置、编辑器设置和工具偏好——但哪些文件应该纳入版本控制?更重要的是,如何在不暴露敏感数据或造成维护噩梦的情况下同步它们?

本文比较了两种最流行的 dotfiles 管理方法——Git bare 仓库和 GNU Stow——同时探讨决定哪些内容应该或不应该提交的关键安全考虑因素。

应该提交什么:安全优先的方法

在选择管理方法之前,先了解哪些内容属于你的 dotfiles 仓库。黄金法则:永远不要提交密钥。

可以安全提交

• Shell 配置(.bashrc、.zshrc、.config/fish/)
• 编辑器设置(.vimrc、.config/nvim/)
• Git 配置(不含凭证的 .gitconfig)
• 终端模拟器配置(.alacritty.yml、.config/kitty/)
• 窗口管理器设置(.config/i3/、.config/sway/)
• 工具配置(.tmux.conf、.config/starship.toml)

永远不要提交

• SSH 私钥(~/.ssh/id_*)
• API 令牌和凭证
• 数据库连接字符串
• 许可证密钥
• 浏览器 cookie 或会话数据
• 命令历史文件(.bash_history、.zsh_history)

对于混合了公开设置和密钥的配置文件,使用模板化方法,或将敏感部分分离到保持本地的独立文件中并通过 source 引入。

Git Bare 仓库:极简主义方法

Git bare 仓库方法将你的 home 目录视为工作树,而不会用 .git 文件夹使其混乱。这种方法除了 Git 之外不需要任何额外工具。

设置过程

git init --bare $HOME/.dotfiles
alias config='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
config config --local status.showUntrackedFiles no

管理文件

config add ~/.vimrc
config commit -m "Add vim configuration"
config push origin main

优点:

• 除 Git 外零依赖
• 无需符号链接的直接版本控制
• 在所有类 Unix 系统上工作方式相同
• 无需中间存储位置

缺点:

• 容易意外提交敏感文件
• 需要严格遵守 .gitignore 规则
• 可能干扰子目录中的其他 Git 仓库
• 对于组织模块化配置不够直观

GNU Stow:有序的方法

GNU Stow 通过符号链接管理 dotfiles,将实际文件组织在专用目录中,同时在 home 文件夹中维护预期的路径。

目录结构

~/.dotfiles/
├── vim/
│   └── .vimrc
├── git/
│   └── .gitconfig
└── shell/
    ├── .bashrc
    └── .zshrc

部署

cd ~/.dotfiles
stow vim git shell  # 在 ~ 中创建符号链接

优点:

• 按应用程序清晰的模块化组织
• 易于在每台机器上选择性部署
• 内置冲突检测
• 支持每个包的忽略文件(.stow-local-ignore)

缺点:

• 需要安装 GNU Stow
• 某些应用程序不能很好地处理符号链接(systemd、某些编辑器)
• 当应用程序覆盖符号链接时可能会出问题
• 需要理解额外的抽象层

选择你的配置管理策略

Git bare 仓库和 GNU Stow 之间的选择取决于你的具体需求:

使用 Git bare 仓库的场景:

• 你希望零依赖
• 你的 dotfiles 相对简单
• 你偏好直接版本控制
• 你熟悉 Git 内部机制

使用 GNU Stow 的场景:

• 你管理复杂的模块化配置
• 你需要按应用程序组织
• 你需要在不同机器上部署不同配置
• 你偏好可视化的目录结构

提升开发者生产力的最佳实践

无论选择哪种方法,都应遵循以下版本控制最佳实践:

1. 积极使用 .gitignore:从 * 开始,显式允许文件
2. 分离公开和私有内容:为敏感配置保留一个私有仓库
3. 记录你的设置:包含安装和部署说明
4. 在全新系统上测试:定期验证你的引导过程
5. 使用条件加载:优雅地处理特定操作系统的配置

对于团队环境,考虑维护一个单独的”标准”配置仓库,提供合理的默认设置,同时允许通过本地覆盖进行个性化定制。

结论

Git bare 仓库和 GNU Stow 都能有效解决 dotfiles 管理问题——选择取决于你的复杂度需求和工具偏好。关键因素不是选择哪种方法,而是在公开配置和敏感数据之间保持严格分离。从安全优先的思维方式开始,选择符合你工作流的方法,你就能拥有一个可移植、版本控制的环境,在不损害安全性的前提下提升开发者生产力。

常见问题

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.