Ansible 与 Git 协同是生产环境主流做法，通过 Git 管理 Playbook、Roles、Inventory 等实现可追溯、可复现、可协作；敏感信息用 Ansible Vault 加密，分支策略联动部署，CI 自动化执行，配合清晰提交和变量抽象保障协作与回滚可靠性。
Ansible 本身不依赖 Git，但和 Git 协同是生产环境中最主流、最可靠的做法——核心在于把 Playbook、Roles、Inventory 等全部当作代码来管理，实现可追溯、可复现、可协作的运维。
用 Git 管理 Ansible 项目结构
一个规范的 Ansible 仓库通常包含以下目录：
-
inventories/：按环境分（如
inventories/prod、inventories/staging），每个环境有 hosts 文件和 group_vars/ 目录 -
playbooks/：存放主执行文件，如
deploy-web.yml、hardening.yml -
roles/：按功能拆分，如
roles/nginx、roles/java，每个 role 包含 tasks、handlers、templates 等标准子目录 - group_vars/ 和 host_vars/：存放变量，Git 可追踪变更
- ansible.cfg：配置文件随项目走，避免依赖全局设置
敏感信息不进 Git：用 Ansible Vault 加密
密码、API Token、私钥等绝不能明文提交。Ansible Vault 提供对文件或变量的加密能力：
- 加密单个变量文件：
ansible-vault encrypt group_vars/prod/vault.yml - 创建新加密文件：
ansible-vault create group_vars/prod/vault.yml - 运行时解密：
ansible-playbook deploy.yml -i inventories/prod --ask-vault-pass（或用--vault-id指定密码文件） - Git 中只保留加密后的内容（以
$ANSIBLE_VAULT开头），配合 CI 环境变量自动解密更安全
分支策略与部署联动
Git 分支不是随意起的，而是直接对应发布流程：
-
main或master：对应生产环境，合并即触发生产部署（需严格 PR 审核+测试门禁） -
staging：对应预发环境，用于冒烟测试和灰度验证 -
feature/xxx：开发分支，仅在本地或 CI 测试中运行 ad-hoc 命令或轻量 Playbook - CI 流水线（如
.gitlab-ci.yml）根据分支自动选择 inventory 并执行对应 Playbook，例如：if: $CI_COMMIT_BRANCH == "main"→ 运行ansible-playbook -i inventories/prod site.yml
协作与版本回滚实战要点
多人共用同一套 Ansible 代码时，关键在“谁改了什么、为什么改、是否影响他人”：
- 每次提交必须写清晰的 commit message，说明修改的模块、影响的环境、是否涉及服务重启
- Playbook 中避免硬编码 IP 或路径，统一用变量（如
{{ nginx_port }}），变量定义在group_vars/下便于环境隔离 - 回滚不是重跑旧 Playbook，而是 检出历史 commit + 重新部署，例如：
git checkout abc1234 && ansible-playbook -i inventories/prod site.yml - 用
ansible --check或--diff在正式执行前预览变更，尤其对文件替换、模板渲染类操作
