上周帮同事调一个 Git 冲突，他本地改了三天的代码，一 push 直接被拒——因为主干（main 分支）上刚合入了另一组人重构的配置模块，接口全变了。这种事在主干开发模式下太常见了，不是谁写得慢，而是没卡住节奏。
什么叫主干开发？
简单说，就是所有人日常开发都基于 main 分支，不拉长期 feature 分支，提交前先 fetch + rebase，保证每次 push 都是线性、可测、可部署的。听起来理想，实际落地时，系统设置类功能最容易翻车：比如 Windows 组策略脚本更新、Linux systemd 服务配置热加载、macOS 的 defaults 命令批量写 plist……这些操作一旦出错，轻则服务起不来，重则整机配置错乱。
别等 CI 报错了再改
我们团队现在强制所有系统设置类提交带本地预检脚本。比如修改 /etc/sysctl.conf 后，必须跑一遍：
sysctl -p /tmp/test.conf && echo "OK" || echo "配置语法错误"再比如改 Windows 注册表导入脚本（.reg 文件），用 PowerShell 先模拟执行：
reg import test.reg /reg:64 /quiet 2>&1 | Out-Null; if ($?) { Write-Host "注册表格式通过" } else { Write-Host "注册表键名或值类型有误" }这类检查不耗几秒，但能拦下 70% 的低级错误。
环境变量和路径，别硬编码
有人写个 Bash 配置脚本，直接写 /home/alex/.bashrc，结果上线到新服务器，用户是 deploy，脚本就静默失效。主干开发里，这类细节暴露得特别快。我们统一改用：
CONFIG_HOME=${XDG_CONFIG_HOME:-"$HOME/.config"}Windows 上也类似，用 %LOCALAPPDATA% 而非 C:\Users\xxx\AppData\Local。
重启不是万能解
改完 systemd service 文件，很多人习惯 systemctl daemon-reload && systemctl restart xxx。但某些服务（比如 udev rules 或 kernel module 加载）需要 reload + trigger 才生效。我们加了一行检测：
udevadm control --reload-rules && udevadm trigger --subsystem-match=usb改完就跑，不等发布后用户报“插U盘没反应”。
主干开发不是追求快，是让每次改动都足够小、足够确定、足够可逆。系统设置类变更尤其如此——它不像前端页面，坏了还能切回旧版；它动的是底座，一松就晃。