最可靠方式是编译时用 git describe 生成版本字符串，如 v1.2.0-5-gabc1234，配合 --always --dirty --abbrev=8 参数确保无 tag 或有修改时仍能输出有效标识，并通过 cmake 的 execute_process 在构建时动态获取并注入 git_version 宏。
编译时用 git describe 生成版本字符串最可靠
直接读取 .git/HEAD 或 .git/refs/heads/* 文件风险高：工作区可能处于分离头状态、子模块未更新、或仓库被裁剪（如 CI 中用 git clone --depth=1）。git describe 能稳定输出带最近 tag 的短哈希（如 v1.2.0-5-gabc1234），且加 --always --dirty 后，即使没 tag 或有未提交变更也能 fallback 到纯哈希 + -dirty 标记。
实操建议：
- 在构建脚本（CMake / Makefile）中执行：
git describe --always --dirty --abbrev=8 2>/dev/null || echo unknown - 把结果存为预处理器宏，例如 CMake 中：
add_compile_definitions(GIT_VERSION=\"${GIT_VER}\") - 确保源码树根目录存在
.git（CI 中别用git archive打包，它不带 Git 元数据）
CMake 中用 execute_process 捕获 Git 输出并注入宏
CMake 是主流选择，但要注意命令执行时机和缓存问题：若只在 configure 阶段运行一次，后续 git commit 后不会自动重触发，导致版本号 stale。必须让 CMake 检测 .git 目录变动，或每次 build 都重新获取。
推荐写法（CMakeLists.txt 片段）：
execute_process(
COMMAND git describe --always --dirty --abbrev=8
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE GIT_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_QUIET
)
if(NOT GIT_VERSION)
set(GIT_VERSION "unknown")
endif()
add_compile_definitions(GIT_VERSION="${GIT_VERSION}")
关键点：
- 必须加
WORKING_DIRECTORY，否则在子目录构建时可能找不到 .git -
ERROR_QUIET防止 git 命令失败时 CMake 报错中断 - 不要用
set(GIT_VERSION ... CACHE ...)，否则不会随 git 状态变化而更新
在 C++ 代码里安全引用 GIT_VERSION 宏
宏展开后是字符串字面量，但若用户提交时含双引号、反斜杠或换行（极少见但可能），直接拼进宏会导致编译失败。不能假设输入干净。
稳妥做法：
- 用 shell 脚本预处理：把
git describe结果用printf %q转义，再喂给 CMake - 更简单的是在 C++ 侧用
constexpr函数做运行时校验（虽无必要，但防呆） - 定义方式统一用：
extern const char* const kGitVersion = GIT_VERSION;，避免宏在 printf 中被误展开
示例使用：
extern const char* const kGitVersion = GIT_VERSION; // … std::cout <h3>静态链接下 <code>.rodata</code> 段可查，但 strip 会清空</h3><p>写入的版本字符串最终落在二进制的只读数据段，可用 <code>strings ./myapp | grep ^v</code> 或 <code>readelf -p .rodata ./myapp</code> 验证。但注意：<code>strip</code> 默认会删掉所有符号和调试段，<code>.rodata</code> 中的字符串常量通常保留——除非你用了 <code>--strip-all</code> 或链接时加 <code>-Wl,--strip-all</code>，这时字符串也会消失。</p><p>验证是否残留的方法：</p>
- 构建后立即运行：
strings ./myapp | grep -E '^[a-f0-9]{7,}' - 如果用
objcopy --strip-unneeded，它比strip温和，一般保留.rodata - 发布前务必在目标环境（如容器内）实际检查二进制，别只信本地开发机结果
Git ID 看似只是个字符串，但一旦涉及自动化发布、故障回溯或灰度标记，它就变成不可信输入——从生成、注入、到落盘，每一步都可能静默失效。最常被忽略的是 CI 环境的 shallow clone 和权限限制，得亲手在 runner 里跑一遍 git describe 看输出才踏实。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
