深色模式
Git 在运维中的使用
摘要：Git 不只是开发用的。把配置、脚本、IaC 代码放进 Git，能获得三样东西：完整变更历史、可评审的 diff、随时可回滚的能力。本文给出运维视角的 Git 工作流：仓库组织、提交规范、敏感信息处理与回滚实操。
适用环境
bash
git --version
git config --global --list | head
which pre-commit || echo "可选工具"1
2
3
2
3
操作步骤
一、初始配置
bash
git config --global user.name "ops"
git config --global user.email "ops@example.com"
git config --global init.defaultBranch main
# 让 git 正确处理中文路径与文件名
git config --global core.quotepath false1
2
3
4
5
2
3
4
5
二、仓库组织：按用途分，不要一个大杂烩
text
ops-infra/ 基础设施即代码（Terraform / Ansible）
ops-configs/ 各环境配置模板与清单
ops-scripts/ 通用脚本
ops-runbooks/ 操作手册与故障记录1
2
3
4
2
3
4
三、把现有配置纳入版本管理
bash
# 例：把 /etc/nginx 纳入管理（不要直接 git init /，范围太大）
cd /etc/nginx
sudo git init
# 敏感文件必须排除
sudo tee .gitignore >/dev/null <<'EOF'
*.key
*.pem
*password*
conf.d/secret.conf
EOF
sudo git add . && sudo git commit -m "nginx: 初始化接入版本管理"1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
危险
私钥、密码、Token 绝不能提交到 Git。即使后续删除，历史记录里依然存在。一旦发现泄露，正确做法不是删文件，而是立即轮换该凭证。
四、分支策略（运维够用的简化版）
text
main ：与生产环境一致，只能合并，不能直接改
feature/*：变更分支，一个变更一个分支
hotfix/* ：紧急修复，走快速通道但最终也要合回 main1
2
3
2
3
bash
git switch -c feature/adjust-nginx-timeout
# 修改配置 ...
git add nginx.conf
git commit -m "nginx: 调大 proxy 超时到 30s，解决大文件上传 504"
git push -u origin feature/adjust-nginx-timeout
# 走评审合并到 main，再由流水线或人工同步到生产1
2
3
4
5
6
2
3
4
5
6
五、提交信息规范
text
格式：<范围>: <动作描述>
nginx: 调大 proxy 超时到 30s
cron: 备份脚本改到 02:10 避开业务高峰
security: 禁用 SSH 密码登录1
2
3
4
5
2
3
4
5
好处是 git log --oneline 能直接当变更日志读：
bash
git log --oneline -20
git log --oneline --since="2 weeks ago" -- nginx.conf1
2
2
六、看 diff 再提交（最重要的一步）
bash
# 提交前必须看清楚改了什么
git diff
# 已 add 的内容看 staged diff
git diff --cached
# 只看文件清单
git diff --stat1
2
3
4
5
6
2
3
4
5
6
注意
git add -A && git commit -m "update" 是运维最危险的习惯之一：一次性提交所有改动，无法分辨哪次改动导致了问题，回滚时也无从下手。应分步 add 并写清每次提交的目的。
七、回滚实操
bash
# 场景一：还没提交，撤销工作区改动
git restore nginx.conf
# 场景二：已提交但未推送，撤销最后一次提交（保留改动）
git reset --soft HEAD~1
# 场景三：已推送，用 revert 生成一个「反向提交」（推荐，不改变历史）
git log --oneline -5
git revert abc1234
git push
# 场景四：找回被删的文件
git log --diff-filter=D --oneline -- path/to/file
git checkout abc1234^ -- path/to/file1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
八、排查「什么时候改坏的」
bash
# 看某行配置是谁、什么时候改的
git blame nginx.conf | grep -n "proxy_timeout"
# 二分查找引入问题的提交
git bisect start
git bisect bad # 当前版本有问题
git bisect good abc1234 # 该版本正常
# 按提示逐次标记 good/bad，git 会自动定位首个坏提交
git bisect reset1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
九、敏感信息处理
bash
# 提交前扫描是否含疑似凭证
git diff --cached | grep -nE "password|secret|token|AKIA|BEGIN RSA PRIVATE" && echo "发现疑似敏感信息！"
# 误提交后的正确处置
# 1) 立即轮换该凭证（最重要）
# 2) 再用 git filter-repo 清理历史（会改写历史，需全员重新 clone）
pip install git-filter-repo
git filter-repo --path secrets.env --invert-paths1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
十、把 Git 与配置下发结合
bash
# 简单可靠的模式：生产机器上从仓库拉取，配合校验与重载
cd /etc/nginx && sudo git fetch --all && sudo git checkout origin/main -- .
sudo nginx -t && sudo systemctl reload nginx1
2
3
2
3
验证
- [ ]
git log --oneline的信息能直接当变更记录读 - [ ] 仓库中不含私钥/密码（用上面的 grep 扫描确认）
- [ ] 一次变更对应一次提交，
git diff内容清晰 - [ ] 演练过一次
git revert回滚并成功恢复 - [ ]
git blame能定位到某一行配置的修改者与时间
常见坑
- 直接在 main 上改生产配置：没有评审与 diff，改错即刻生效。
- 提交敏感文件：轮换成本远高于当时省下的事。
- 一次性提交大量无关改动：无法定位问题变更，回滚困难。
- 仓库里放大型二进制：仓库体积迅速膨胀，clone 变慢，应放对象存储。
- Git 仓库与实际配置不同步：有人手工改了线上但没提交，Git 内容不再可信，应尽量做到「只允许通过仓库下发」。