Deployer `dep push` 开发热推送详解：将本地改动即时同步到远端而不经过 Git

Deployerdep push开发热推送详解将本地改动即时同步到远端而不经过 Git【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址: https://gitcode.com/gh_mirrors/de/deployerdep push是 Deployer 官方recipe/deploy/push.php配方提供的一个开发专用任务它绕过常规的“提交 → 推送 →deploy拉取”流程直接把本地工作区的改动以 rsync 增量方式同步到远端当前发布目录并打上DIRTY_RELEASE脏标记。读完本文你将掌握push任务的注册方式、执行机制、DIRTY_RELEASE标记在前端dep releases展示中的含义以及如何基于源码扩展或定制这一热更新能力。一、任务定位为什么需要pushDeployer 的常规部署流程如deploy任务链依赖 Git本地提交后推送到远程仓库远端主机执行deploy:update_code拉取并构建新 release。这一流程在每次修改都需要走一遍“提交—推送—部署”时显得笨重。push任务正是为开发阶段设计的轻量通道。官方 getting-started 明确指出开发过程中dep push无需经过 Git就能把本地改动作为“补丁”直接投递到远端主机During development,dep pushships a patch of local changes to the host without going through git.它不会创建新的 release、不更新REVISION、不切换符号链接而是直接覆盖写入current_path指向的目录因此只适合开发环境这是原文档反复强调的使用前提。二、注册与调用1. 在部署配置中引入配方push任务定义在 recipe/deploy/push.php通过require引入通常写入deploy.phprequire recipe/deploy/push.php;引入后运行dep list即可看到push任务出现在任务列表中。2. 命令行执行dep push也可以指定主机执行dep push staging命令发出后Deployer 会先展示待上传文件清单再通过 rsync 完成增量传输。三、任务执行流程逐步拆解push任务的完整定义只有短短十几行recipe/deploy/push.php却完成了“收集改动 → 预览清单 → 增量上传 → 脏标记”四个关键步骤desc(Pushes local changes to remote host); task(push, function () { $files explode(\n, runLocally(git diff --name-only HEAD)); info(uploading:); foreach ($files as $file) { writeln( - $file); } upload( $files, {{current_path}}, [progress_bar false, options [--relative]], ); // Mark this release as dirty. run(echo {{user}} {{current_path}}/DIRTY_RELEASE); });步骤一用git diff收集本地改动文件$files explode(\n, runLocally(git diff --name-only HEAD));runLocally在本机而非远端执行命令底层走Deployer::get()-processRunner默认以bash -s为 shell见 src/functions.php。git diff --name-only HEAD输出“自 HEAD 以来已修改但尚未提交”的文件名每行一个结果按换行符切分得到文件数组。限制一仅追踪未提交的已跟踪文件改动。新建但未git add的文件不会出现在git diff输出中已提交的改动同样不会包含。如果需要覆盖未跟踪文件可扩展为git status --porcelain之类的方式见后文“自定义与扩展”。步骤二预览上传清单info(uploading:); foreach ($files as $file) { writeln( - $file); }在真正传输前info与writeln会逐行打印将上传的文件writeln输出时自动带上前缀[host]见 src/functions.php便于确认本次推送范围。步骤三rsync 增量上传到current_pathupload( $files, {{current_path}}, [progress_bar false, options [--relative]], );upload()是 Deployer 的全局函数src/functions.php内部委托给Deployer\Utility\Rsyncsrc/Utility/Rsync.php。这里有两个值得注意的细节--relative选项这是push的灵魂。rsync 的-R/--relative会让源文件带上其相对路径结构。例如本地的app/Controller/HomeController.php目标端也会落在{{current_path}}/app/Controller/HomeController.php而不是被摊平到目标根目录。这正是“以当前路径为根、就地覆盖改动”所必需的。progress_bar false关闭传输进度条。查看 src/Utility/Rsync.php 可知upload的默认配置为flags: -azP、progress_bar: true、timeout: nullpush主动关闭进度条以保持清单式输出简洁。最终 rsync 命令形如rsync -azP --relative file1 file2 ... userhost:current_path其中-a归档、-z压缩、-P断点续传兼进度显示如果主机配置了become提权用户Rsync 类还会自动追加--rsync-path sudo -H -u user rsyncsrc/Utility/Rsync.php。限制二current_path通常是当前 release 的符号链接如releases/2的链接current所以push写入的是正在使用的发布目录而非新 release——这正是它“可多次执行、反复热更”的原因原文档明确说明 “Push can be done many times”。步骤四写入DIRTY_RELEASE脏标记run(echo {{user}} {{current_path}}/DIRTY_RELEASE);run在远端执行命令{{user}}是配置中的部署用户名Deployer 会先对命令做{{占位符}}解析见 src/functions.php。该命令把当前用户写入{{current_path}}/DIRTY_RELEASE文件表明这个 release 已被“手工污染”——其内容不再与 Git 仓库中的任何提交一致。这个标记在dep releases中被读取。查看 recipe/deploy/release.php 的展示逻辑if (test([ -f releases/$release/BAD_RELEASE ])) { $status error$release/error (bad); } elseif (test([ -f releases/$release/DIRTY_RELEASE ])) { $status error$release/error (dirty); } else { $status info$release/info; }即被push过的 release 在dep releases表格中会以红色(dirty)状态呈现提醒开发者“此 release 已被直接改过不能代表一个干净的发布产物”。这是原文档未展开、但从源码可确认的联动行为也是DIRTY_RELEASE标记存在的全部意义。四、底层原理与调用链push的完整调用链可以归纳为runLocally(git diff --name-only HEAD)→ProcessRunner::run在本机执行 Git 命令src/functions.phpupload($files, {{current_path}}, [...])→Rsync::call组装并运行 rsyncsrc/functions.php、src/Utility/Rsync.phprun(echo {{user}} .../DIRTY_RELEASE)→ 远端经 SSH 执行本地主机则直接跑进程实现“写标记”副作用。三个环节分别对应“本地采集”“网络传输”“远端落盘”职责清晰。runLocally与run的差别在于前者始终在本地new Localhost()执行且 shell 默认bash -s后者根据当前主机类型自动选择 SSH 客户端或本地进程src/functions.php。五、自定义与扩展push与 Deployer 其他任务一样可通过task(push, ...)在deploy.php中覆盖重定义以适配不同工作流。例如将“未跟踪文件”也纳入同步并同步删除远端多余文件task(push, function () { $files array_map( static fn($line) substr($line, 3), // 去掉 ?? 等状态前缀 explode(\n, runLocally(git status --porcelain)), ); $files array_values(array_filter($files, strlen)); info(uploading:); foreach ($files as $file) { writeln( - $file); } upload($files, {{current_path}}, [ progress_bar false, options [--relative, --delete], ]); run(echo {{user}} {{current_path}}/DIRTY_RELEASE); });注意--delete会删除远端目标中本地已不存在的文件热更范围更彻底但也更激进务必仅在开发环境使用。六、使用注意事项与限制综合原文档与源码使用push时应牢记以下几点事项说明适用环境仅限开发。原文档明确 “The task purpose to be used only for development.”可重复执行可多次执行“Push can be done many times”每次覆盖写入current_path改动来源仅git diff --name-only HEAD命中的已跟踪未提交文件写入目标直接写{{current_path}}不新建 release、不更新REVISION脏标记写入后该 release 在dep releases中显示为(dirty)依赖本地需为 Git 仓库且存在 HEAD远端需可执行 rsync 与 shell 命令与正式部署的关系被污染的 release 不代表干净的发布产物正式上线前应重新走完整deploy流程七、相关文档导航任务定义源码recipe/deploy/push.php上传底层实现src/functions.phpupload/runLocally/run与 src/Utility/Rsync.php脏标记消费方recipe/deploy/release.phpdep releases的(dirty)展示开发工作流上下文docs/getting-started.md通用任务一览docs/recipe/common.md其中列出了push等 deploy 相关任务入口总结push用最精简的实现解决了“开发期即时同步”这一高频痛点——git diff收集、rsync--relative就地覆盖、DIRTY_RELEASE状态标记三件套配合dep releases的脏状态可视化让开发者既能享受热更的便捷又不会在正式发布时误用被污染的目录。理解其源码级行为后你完全可以按需扩展出属于自己的开发热更新流程。【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址: https://gitcode.com/gh_mirrors/de/deployer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考