多分支协作项目中Docker镜像标记的最佳实践有哪些？

你提到的<version>-<commit_hash>-<branch_name>是行业通用的基础标签方案，完全适用于你的多团队feature分支开发、需要快速定位团队/分支镜像的场景，在此基础上做少量标准化调整即可落地。

标签设计核心原则 #

设计标签时需要满足三个基础要求，避免后续出现部署、追溯问题：

• 全局唯一：每个构建产出的镜像标签必须唯一，禁止重复使用同个标签推送不同镜像，避免部署时出现版本混淆
• 语义化可读：无需查询CI/仓库后台，直接通过标签即可识别镜像的版本归属、来源分支、代码版本
• 兼容仓库规则：符合Azure Container Registry（以及绝大多数容器镜像仓库）的标签规范，只能包含小写字母、数字、-、.、_，总长度不超过128字符

推荐落地标签方案 #

基础通用方案（适配90%以上场景） #

在你提到的基础格式上做标准化调整后格式如下：
<语义化版本>-<短commit哈希>-<标准化分支名>
各字段说明：

• 语义化版本：对应C#项目的程序集版本，开发版本可增加预览标识，例如1.2.3、1.2.3-preview
• 短commit哈希：取Git提交哈希的前7位，例如f3d9a2c，保证每次构建的标签全局唯一，即使同一分支多次提交构建也能区分版本
• 标准化分支名：将分支名中的特殊字符（如/、#）替换为-，例如分支feature/order-pay-module转换为feature-order-pay-module，直接通过标签即可识别所属团队、对应需求分支
  实际生成示例：1.2.3-preview-f3d9a2c-feature-order-pay-module

可选扩展字段 #

如果有额外的场景需求，可以在基础格式上补充字段：

• 需要区分部署环境的场景，可增加环境前缀：dev-1.2.3-f3d9a2c-feature-order-pay-module
• 需要关联CI流水线构建记录的场景，可增加构建ID后缀：1.2.3-f3d9a2c-feature-order-pay-module-20240520.47

配套落地注意事项 #

• 所有标签的生成逻辑完全集成在CI流水线中自动执行，禁止人工手动打标签，避免出现格式不一致、标签重复的问题
• 正式发布的生产版本可额外追加固定版本标签，例如1.2.3、latest-stable，方便生产环境拉取固定版本
• 配置ACR生命周期管理规则，自动清理超过30天的feature分支旧镜像，避免仓库存储资源浪费
• 禁止使用latest标签作为多分支开发场景的部署标识，latest标签默认覆盖更新，会导致版本不可追溯

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