如何管控生成多release版本目录的Git部署流程

你看到的deploy/releases/[数字版本号]多版本目录结构，是版本化滚动发布方案的标准结构，最早是Capistrano部署工具的默认规范，现在大量自定义部署脚本、GitHub Actions封装的各类项目发布流程都复用这套逻辑：

• 每次执行部署会生成一个独立的、以版本序号命名的文件夹，存放当次发布的全量项目代码
• 站点实际访问的根目录是指向当前生效版本文件夹的软链接，你提到的108就是当前软链指向的线上生效版本
• 同目录下的1、106、107是历史发布留存的旧版本，作用是发布出问题时可以秒级回滚，不需要手动修改这些目录下的内容
• 标准结构下同路径还会有shared目录，存放环境配置文件、用户上传资源等跨版本需要保留的公共文件，以及current软链直接指向当前生效版本。

从你查到的工作流记录可以确定，这套部署流程由GitHub Actions驱动：

• 部署触发条件一般是代码合入指定分支、打对应格式的版本tag，部署时使用的身份不是个人Git账号，是仓库内置的GITHUB_TOKEN，或是提前配置在仓库密钥中的服务器SSH部署密钥
• 部署日志里的Git操作记录，是部署流程在服务器端拉取代码、归档版本的自动操作，不绑定某一个开发者的个人账号
• 注意：直接在releases/108目录下修改代码属于临时操作，下次自动部署触发后，所有手动修改的内容会被新版本完全覆盖。

• 首先获取对应GitHub仓库的写入/管理员权限：进入仓库后就能在Actions板块查看所有历史部署记录、触发来源、运行日志，仓库内.github/workflows/路径下存放了完整的部署配置脚本，可以直接修改发布规则、触发条件
• 其次获取部署目标服务器的SSH登录权限：登录服务器后进入部署根目录，执行ls -l deploy/current即可验证软链是否指向当前的108版本，后续回滚、清理历史版本、调整共享目录配置都可以在服务器端操作
• 最后核对仓库密钥配置：在仓库Settings - Secrets and variables - Actions路径下，可以查看部署用的SSH密钥、服务器连接地址、部署路径等所有核心配置，权限确认后可以更新密钥、调整部署目标环境。

提示：不要手动删除releases目录下的旧版本文件夹，标准部署流程会自动配置历史版本留存数量（通常保留5-10个版本），手动删除会导致版本回滚功能失效。

内容的提问来源于stack exchange，提问作者Ahmed Syed