Linux自动化部署脚本的版本控制本质是将部署逻辑代码化并统一纳入Git管理，涵盖部署脚本、配置模板、Ansible资源、CI/CD定义及Dockerfile等，敏感信息加密处理，按分支映射环境实现代码流驱动发布，CI配置即代码确保可复现，脚本需幂等、支持回滚与日志审计。
Linux 下自动化部署脚本的版本控制，本质是把“部署逻辑”当作代码来管理——不是只管应用代码，连部署用的 Shell 脚本、Ansible Playbook、CI 配置文件（如 .gitlab-ci.yml 或 Jenkinsfile）都要纳入 Git 仓库统一追踪。
所有部署资产必须进 Git 仓库
不能只放源码，还要包含：
- 部署脚本（
deploy.sh、rollback.sh） - 配置模板与环境变量文件（
config/staging.env、templates/nginx.conf.j2） - Ansible 目录结构（
inventories/、roles/、playbooks/） - CI/CD 流水线定义（
.gitlab-ci.yml、Jenkinsfile） - 构建镜像用的
Dockerfile和build.sh
敏感信息（密码、密钥）不直接提交，改用 Ansible Vault 加密或 CI 平台的 secret 变量机制。
按环境分分支，合并即部署
用 Git 分支映射部署环境，让代码流驱动发布流：
-
main分支 → 自动触发生产部署（需 PR + 人工审批） -
staging分支 → 推送后自动部署到预发环境 -
feature/*分支 → 仅运行单元测试和语法检查，不部署
在 CI 配置中用 rules 或 only/except 精确限定每个任务的触发条件，避免误操作。
Git Worktree
下载
Git Worktree 多需求并行开发助手：在当前 worktree 目录独立开发、修改、提交代码，不跨目录。基于目录命名规范自动识别仓库归属（如 main-repo-feature‑a → main‑repo 仓库）。遵循最小改动原则，从需求分析到 commit 交付全流程负责。触发场景：用户在 ...
流水线定义本身也要可复现
CI 配置文件（如 Jenkinsfile）不是写在 Jenkins Web 界面里的，而是放在项目根目录下，随代码一起提交。这样：
- 每次修改部署逻辑都有 Git 提交记录，能追溯谁、何时、为何改了部署方式
- 新成员拉取代码就能直接看到完整部署流程，无需翻文档或问老同事
- 回滚部署行为，只需
git checkout到上一个稳定 commit，再触发构建即可
进阶做法：用 Jenkins Configuration as Code（JCasC）把 Jenkins 全局配置也存进 Git，实现整套 CI 环境的版本化重建。
脚本设计要支持幂等与回滚
部署脚本不能假设“目标环境干净”，而要能反复执行且结果一致（幂等）：
- 用
systemctl is-active --quiet nginx判断服务状态，而非盲目start - 部署前备份旧配置，失败时自动还原（
cp -f config.bak /etc/nginx/conf.d/app.conf） - 提供独立的
./rollback.sh --to=20260610-1422命令，按时间戳或 Git tag 回退
每一步执行都记录日志（exec >> /var/log/deploy-$(date +%Y%m%d).log 2>&1），便于事后审计与故障定位。
