开发环境管理：用 dotfiles 维护终端、编辑器和常用工具

一、为什么要管理开发环境

开发环境一旦积累几年，就会变成很多零散配置：Shell、Git、编辑器、终端主题、常用脚本、SSH 配置、语言工具链。换电脑或重装系统时，如果没有记录，恢复成本很高。

dotfiles 的目标不是炫技，而是让环境可复制、可审查、可迁移。

适合纳入管理的内容：

• .bashrc、.zshrc。
• .gitconfig。
• 编辑器配置。
• 终端主题和快捷键。
• 常用命令别名。
• 安装脚本。
• 本地工具脚本。

不适合提交的内容：

• 私钥。
• 访问令牌。
• 公司内部密码。
• 机器专属路径。
• 大型二进制文件。

二、先从 Git 配置开始

Git 配置最容易收益。

[user]
    name = your-name
    email = your-email@example.com

[alias]
    st = status --short
    co = checkout
    br = branch
    lg = log --oneline --graph --decorate --all

[core]
    editor = vim

常用别名能减少输入，但不要把危险操作封装得太短。例如强推、重置和删除分支，最好保持显式命令，避免误操作。

三、Shell 配置保持克制

Shell 配置最容易越写越乱。建议把内容拆成几个小文件。

shell/
  aliases.sh
  exports.sh
  path.sh
  functions.sh

主配置文件只负责加载：

for file in "$HOME/.config/shell/"*.sh; do
  [ -r "$file" ] && source "$file"
done

这样排查问题更方便，也能按模块迁移。

四、别名应该服务高频操作

好的别名应该短、清楚、低风险。

示例：

alias ll='ls -lah'
alias gs='git status --short'
alias gd='git diff'
alias gdc='git diff --cached'
alias ports='ss -lntp'
alias myip='curl -s https://ifconfig.me'

不要给复杂命令起过于隐晦的名字。几个月后自己看不懂，维护成本会反过来抵消收益。

五、编辑器配置要可迁移

编辑器配置建议区分“通用配置”和“机器配置”。

通用配置：

• 缩进宽度。
• 保存时格式化。
• 常用插件列表。
• 主题和字体偏好。
• 语言服务器配置。

机器配置：

• 本地 SDK 路径。
• 公司项目路径。
• 特定机器的性能选项。

如果编辑器支持同步配置，也可以用官方同步功能。但关键配置仍然建议保留一份文本化备份，方便审查和回滚。

六、安装脚本不要过度自动化

很多 dotfiles 项目会写一个巨大的安装脚本，试图一键配置所有环境。看起来很方便，但也容易不可控。

更稳的方式是拆成多个脚本：

install/
  packages.sh
  git.sh
  shell.sh
  editor.sh
  node.sh
  python.sh

每个脚本只做一类事情，并且可以重复执行。安装脚本应该尽量幂等，重复运行不会破坏已有环境。

七、敏感信息单独处理

dotfiles 仓库很可能是公开或半公开的。敏感信息必须从设计上隔离。

建议：

• 使用 .gitignore 忽略本地 secret 文件。
• 在配置中引用环境变量。
• 提供 .example 示例文件。
• 不提交真实 token。
• 不提交 SSH 私钥。

示例：

export OPENAI_API_KEY="从本地 secret 文件加载"

真实值应该放在未提交的本地文件、系统密钥链或专门的凭据管理工具里。

八、跨平台时少写硬编码

如果需要同时支持 Linux 和 macOS，要避免硬编码命令路径。

可以按系统判断：

case "$(uname -s)" in
  Darwin)
    export PLATFORM="macos"
    ;;
  Linux)
    export PLATFORM="linux"
    ;;
esac

差异比较大的地方，宁可拆成不同文件，也不要在一个脚本里堆满复杂判断。

九、保留恢复说明

dotfiles 仓库里应该有一份简单 README，说明新机器怎么恢复。

内容包括：

• 需要先安装哪些基础工具。
• 如何克隆仓库。
• 如何创建软链接。
• 哪些脚本可以执行。
• 哪些配置需要手动填写。
• 如何回滚。

文档不需要很长，但必须能让未来的自己看懂。

十、从最小集合开始

一开始不要试图把所有环境都自动化。可以先管理这几类：

.gitconfig
shell aliases
editor settings
常用脚本
安装说明

等这些稳定后，再逐步加入语言工具链、窗口管理、终端主题和系统偏好。

开发环境管理的价值在长期。每次换机器少折腾一天，每次排查少翻一次历史记录，dotfiles 就已经值得维护。