Git标签命名不合规导致CI构建失败，因正则校验^ [0-9]+\.[0-9]+\.[0-9]+$不匹配v1或dev-2024等非语义化标签；须用git tag -a v1.2.0 -m "release"创建注解标签，禁用轻量标签，并统一团队分隔符规则与镜像不可变实践。
Git标签命名不合规导致CI构建失败
CI流水线拉取v1或dev-2024这类非语义化标签时，常因正则校验失败直接中断构建。这不是Git报错，而是CI脚本里写的if [[ $TAG =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]匹配不上。
- 必须用
git tag -a v1.2.0 -m "release"创建带注解的标签，轻量标签（git tag v1.2.0）无法被多数CI工具识别为正式发布点 - 避免在标签里混用分隔符：
v1_2_0、v1.2.0-beta.1（多级预发布）虽合法，但需提前统一团队正则规则 - CI中解析标签时，优先用
git describe --tags --exact-match而非git rev-parse HEAD，后者返回的是commit hash，不是标签名
Docker镜像标签被覆盖后下游服务拉不到预期版本
你推送了myapp:1.2.0，运维却在K8s里看到容器实际运行的是旧版逻辑——大概率是有人后来又用相同标签推了新镜像，而1.2.0这个标签已被重新指向另一个镜像ID。
- 生产环境绝不允许
docker push myapp:1.2.0重复执行；每次变更必须升版本号，哪怕只是文档更新 - CI脚本里加一层保护：推送前先查远程是否存在同名标签，用
curl -I https://registry.example.com/v2/myapp/manifests/1.2.0 2>/dev/null | head -n1 | grep "HTTP/1.1 200" - 真正需要不可变性的场景，直接用摘要拉取：
docker pull myapp@sha256:abc123...，但得把摘要值存进部署清单，不能靠人肉复制
SVN标签目录结构混乱引发分支合并冲突
SVN里把tags/v1.0建成了普通目录而非通过svn copy生成，结果后续svn merge时提示E160004: No such revision——因为tag没记录原始revision信息，merge引擎找不到基线。
- 必须用
svn copy ^/trunk ^/tags/v1.0 -m "tag v1.0"，不能svn mkdir再svn add - 检查已有tag是否合规：
svn log -l1 ^/tags/v1.0应显示copy操作记录，而不是普通commit - 若已误建，只能删掉整个
tags/v1.0目录，重新copy；不要试图用svn propset补元数据，SVN不认
LabelMe标注项目里JSON文件提交后diff不可读
多人同时修改同一张图的image_001.json，Git diff显示整段JSON重排，看不出谁改了哪个polygon坐标——这并非Git问题，而是JSON序列化格式不统一。
- 所有标注工具导出前强制执行
jq -S . image_001.json > image_001.json（-S参数保证键名排序一致） - 在
.gitattributes里声明：*.json diff=json，让Git调用内置JSON差异处理器 - 禁止手动编辑JSON：LabelMe保存时默认不格式化，必须配合pre-commit hook自动标准化，否则每次提交都触发全文件diff
