运维脚本是需持续迭代的核心资产，应通过Git规范管理：统一存放于/opt/scripts，用裸仓库或工作仓库初始化，配置.gitignore，提交需遵循type(scope): subject格式并附上下文，配置文件纳入版本控制但隔离敏感数据，分支策略采用main/staging/dev，发布打tag且禁止直推main。
运维脚本不是写完就扔的临时工具，而是需要持续迭代、多人协作、随时回滚的核心资产。用 Git 管理 Shell 脚本代码库，本质是把“自动化能力”变成可追溯、可协作、可审计的生产要素。
脚本仓库初始化要规范
不要直接在 /root 或 /home 下建 git 仓库。推荐做法是统一存放于 /opt/scripts 或 /srv/scripts，并设置合理权限：
- 创建专用目录：
sudo mkdir -p /opt/scripts && sudo chown root:wheel /opt/scripts - 初始化空仓库：
cd /opt/scripts && git init --bare scripts.git（裸仓库适合集中管理） - 或本地工作仓库：
git init && git add . && git commit -m "init: add core monitoring and backup scripts" - 配置忽略项：在 .gitignore 中加入
*.log、tmp/、__pycache__/（即使纯 shell 也常混用 Python 工具）
提交必须带上下文信息
运维脚本的每次变更都可能影响线上服务，commit message 不是可选项，而是故障定位的第一线索：
- 格式建议：
type(scope): subject，例如fix(nginx): correct proxy timeout in reload.sh或feat(backup): add retention policy to daily_backup.sh - 避免模糊描述如 “update script” 或 “fix bug”，要明确改了什么、为什么改、影响范围
- 敏感操作（如用户删除、防火墙规则变更）建议在 commit body 中附上变更前后的关键行对比或执行命令示例
配置文件也要进 Git，但得隔离敏感数据
/etc 下的配置不是代码，却是运维状态的关键镜像。纳入版本控制能防止“谁改的？什么时候改的？改对了吗？”三连问：
- 用
git add --chmod=600 /etc/nginx/nginx.conf保留权限，避免误提交明文密码 - 敏感字段（如数据库密码、API key）应抽离为变量，存于独立加密文件或环境变量中，Git 只跟踪模板（如 nginx.conf.tpl）
- 配合
git blame /etc/sysconfig/firewalld快速定位某行配置的修改人和时间，比翻日志快得多
日常协作靠分支+标签，不靠直接改 main
运维场景里，“上线即生效”，所以分支策略要兼顾安全与效率：
- 约定主干分支：main（生产稳定版）、staging（预发验证）、dev（日常开发）
- 功能/修复必须新建分支：
git checkout -b fix/logrotate-cron-overflow，完成后 MR/PR 合并 - 每次发布打 tag：
git tag -a v2.1.0 -m "deploy: add log rotation for auditd + nginx"，便于快速回溯部署点 - 禁止直接 push 到 main —— 即使单人维护，也养成
git checkout -b hotfix && git push origin hotfix的习惯
