直接在构建时注入Git提交哈希是最轻量可靠的版本追溯方式，需通过--build-arg传入git rev-parse HEAD结果，在Dockerfile中用ARG声明并写入/app/COMMIT_ID文件或ENV固化，再通过docker run或inspect验证一致性。
直接在构建时把 Git 提交哈希写进镜像，是最轻量、最可靠的版本追溯方式。关键不是“能不能”，而是“怎么确保每次构建都准确带入当前代码状态”。
用 --build-arg 传入 commit ID
Docker 构建本身不自动读取 Git 信息，必须显式传入。推荐在构建命令中直接调用 git rev-parse HEAD：
- 执行：
docker build --build-arg GIT_COMMIT=$(git rev-parse HEAD) -t myapp:latest . -
--build-arg是唯一安全的传参方式，避免硬编码或依赖构建环境变量 - 如果当前不在 Git 仓库根目录，
git rev-parse HEAD会失败，需确保工作目录正确
在 Dockerfile 中接收并固化
仅声明 ARG 不够，它只在构建阶段存在，必须转成持久化内容：
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 用
ARG GIT_COMMIT声明参数，再用ENV GIT_COMMIT=$GIT_COMMIT或RUN echo "$GIT_COMMIT" > /app/COMMIT_ID - 优先写入文件（如
/app/COMMIT_ID），比环境变量更稳定——容器启动时不会被docker run -e覆盖 - 不要用
LABEL git.commit=...存敏感信息，LABEL 可被docker inspect查看，但不适合存大量文本或二进制内容
验证注入是否生效
构建完成后，立刻检查镜像里有没有你想要的指纹：
- 查看文件：
docker run --rm myapp:latest cat /app/COMMIT_ID - 查环境变量：
docker inspect myapp:latest | jq '.[0].Config.Env' - 比对是否和当前本地
git rev-parse HEAD输出一致，避免缓存导致旧 commit 被复用
配合 CI 自动化打标签
在 GitHub Actions 或 GitLab CI 中，可把 commit ID 直接变成镜像 tag：
- 例如在 workflow 中：
docker build --build-arg GIT_COMMIT=${{ github.sha }} -t myrepo/myapp:${{ github.sha }} . - 也可组合使用分支名 + commit：
-t myrepo/myapp:${{ github.head_ref }}-${{ github.sha }} - 注意：GitHub Actions 的
${{ github.sha }}是触发 workflow 的那次提交，不是构建时的 HEAD（若中间有新 push，需用 checkout action 拉取最新）
