在为 Docker 项目配置好 GitHub Actions 工作流，并通过构建缓存优化流程之后，还可以继续完善发布策略。一个常见做法是：不要在每次提交到主分支时都更新 Docker Hub 上的镜像，而是仅在打上指定版本标签时再执行发布。
这种方式更适合规范化的镜像交付流程。日常提交可以继续用于测试或内部验证，而正式版本则通过标签进行管理并推送到 Docker Hub，从而避免“latest”频繁变动带来的混乱。
如果你需要在本地注册表或其他环境中持续验证最新代码，这种模式也很实用。这样既能始终测试最新提交，又能把带标签的稳定版本单独保留下来用于正式发布。
整体思路
实现这一流程通常包括两个部分：
- 修改 GitHub Actions 工作流，仅在提交带有特定版本标签时推送镜像到 Docker Hub。
- 新增一个 GitHub Actions 工作流，将最新提交构建后的镜像保存到 GitHub Container Registry，供测试或协作使用。
仅在打标签时推送到 Docker Hub
首先，可以调整现有工作流的触发条件，让它只在特定格式的标签被推送时执行。例如：
on:
tags:
"v*.*.*"
这表示只有当提交被打上类似 v1.0.2 这样的版本标签后，相关 CI 流程才会触发并执行发布。
例如，可以在本地运行以下命令：
Git tag -a v1.0.2
Git pUSh oRigin v1.0.2
完成后，到 GitHub 仓库的 Actions 页面中查看工作流是否已按预期触发。
将最新提交推送到 GitHub 容器注册表
除了正式版本发布之外，还可以再配置一个单独的 GitHub Actions 工作流，把最新提交构建成镜像并推送到 GitHub Container Registry。
这样做通常有两个用途：
- 用于夜间测试、回归测试或持续验证最新代码。
- 便于与团队成员共享当前开发中的镜像。
可以基于之前已有的 GitHub Actions 配置复制出一个新工作流，并恢复“对所有推送都执行构建”的逻辑。这样一来，仓库中就会同时存在两个工作流：一个负责版本标签发布到 Docker Hub，另一个负责将日常提交推送到 GitHub 的容器注册表。
接下来，需要把原本使用的 Docker Hub 登录配置改为 GitHub Container Registry 的登录配置。
调整镜像标签策略
在推送到 GitHub 容器注册表时，还需要修改镜像标签的生成方式。下面的示例将镜像统一标记为“latest”，当然你也可以根据分支名、提交哈希或时间戳扩展出更细致的规则。
tags: ghcR.io/${{ Github.ReposiTory_owneR }}/siMpleWhale:latest
拆分不同场景下的镜像流程
完成上述设置后，整个流程会更加清晰：
- 带版本标签的提交：推送到 Docker Hub，用于正式发布。
- 主分支上的最新提交或日常推送：推送到 GitHub Container Registry，用于测试和协作。
- 拉取请求相关构建：也可以统一调整为推送到 GitHub 容器注册表，而不是 Docker Hub。
这样可以把开发中的镜像与正式发布镜像有效区分开，既提升了版本管理的可控性，也让测试与发布流程更加稳定。
