Git多分支打包时版本信息必须从当前检出分支实时获取，需通过脚本生成version.txt（含分支名、短commit、作者时间）并随git archive一并打包，Jenkins中优先使用env.BRANCH_NAME，Webpack/Vite构建须安全执行git命令并统一注入__GIT_INFO__对象。
直接说结论：Git多分支打包时，版本信息必须从当前检出分支的上下文实时获取，不能硬编码、不能跨分支复用、也不能依赖构建后手动补录——否则分支A打包出来的文件里写着分支B的commit，排查时会彻底失焦。
git archive 打包时如何保留当前分支元数据
用 git archive 打包本身不带分支名或提交人等信息，它只导出文件快照。想让打包产物自带分支标识，得在打包前生成描述文件并一并归档。
- 不要用
git archive --format=zip --output=dist.zip HEAD单独打包，这样没任何版本线索 - 先执行脚本生成
version.txt（内容含env.BRANCH_NAME、git rev-parse --short HEAD、git show -s --format="%an %ad" HEAD） - 再用
git archive --format=zip --output=dist.zip HEAD version.txt把描述文件一起打进去 - 注意：如果脚本在 CI 环境运行，确保工作区已完整检出（
git fetch --all+git checkout $BRANCH），否则HEAD可能指向 detached state
Jenkins 多分支流水线中正确读取分支名和 commit 信息
在 Jenkinsfile 里写 sh 'git rev-parse --abbrev-ref HEAD' 得到的可能是 HEAD 而不是真实分支名——因为 Multibranch Pipeline 默认以 detached HEAD 方式检出。必须依赖 Jenkins 注入的环境变量或显式 checkout。
alfred-github-backup
下载
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
-
env.BRANCH_NAME是最可靠来源，它由 SCM 插件解析 Webhook 的ref字段而来，值如feature/login或release/2.1 - 不要在
script块里调用git checkout后再读env.GIT_COMMIT，该变量不会自动刷新 - 若需额外 Git 信息（如 tag、author email），用
sh(returnStdout: true, script: 'git show -s --format="%H %ce" HEAD').trim() - 参数化构建中传入
BRANCH_NAME时，checkout 必须显式写成checkout([$class: 'GitSCM', branches: [[name: "origin/${params.BRANCH_NAME}"]], ...])，否则 Jenkins 仍按默认策略检出
Webpack/Vite 构建时注入 Git 分支信息的避坑点
Webpack 插件或 Vite 插件在 buildStart 钩子中执行 execSync('git ...') 是常见做法，但容易因路径、权限或 CI 环境缺失 .git 目录而失败。
- 务必用
cwd: process.cwd()显式指定子进程工作目录，避免在 monorepo 中误读子包的 .git - 加 try/catch 包裹
execSync，并在 catch 中 fallback 到空对象或占位字符串，防止构建中断 - 不要把分支名直接拼进 JS 变量名（如
const branch_${env.BRANCH_NAME} = ...），会触发语法错误；应统一存为__GIT_INFO__这样的常量对象 - Vite 用户注意：
define中的值是编译期替换，无法动态读取 Git，必须走插件 +import.meta.env注入或生成 runtime 文件
真正麻烦的不是怎么取分支名，而是当一个仓库同时存在 feature/release/hotfix 多种分支策略时，env.BRANCH_NAME 的值可能为 feature/foo、release/v3.0 或 hotfix/bug-123——你的版本文件命名规则、日志前缀、甚至部署路由都要能区分这三类语义，否则上线后根本分不清这是预发还是热修。
