| name | dbm-release-plan |
| description | 生成 frontend_master 待合入 v1.5.0 的 commit 发布计划记录。当用户需要发布计划、 发版记录、核对 frontend_master 还有哪些提交未合入 v1.5.0，或给出 release PR 链接 要求生成 commit 清单时使用。是否已合入的判定逻辑：以 commit msg 尾部的 issue id （如 #19152）在 v1.5.0 历史中是否存在相同 issue id 的提交为准（识别 cherry-pick）。 |
| disable-model-invocation | true |
dbm-release-plan
生成 frontend_master 相对 v1.5.0 的发布计划 commit 记录。
判定逻辑
- 用
git log base/v1.5.0..base/frontend_master --no-merges 拿到 frontend_master 领先的所有提交。
- 从每条 commit msg 尾部提取 issue id（
#数字，取最后一个匹配）。
- 在
v1.5.0 历史中 --grep 搜索相同 issue id：
- 搜到 → 已合入（通常是被 cherry-pick 过去，SHA 不同但 issue id 相同）
- 搜不到 → 未合入，列入发布计划
- 无 issue id 的提交单独标注，需人工确认。
远程仓库约定
base 指向 TencentBlueKing/blueking-dbm（主仓库）。- 若本地无
base 远程，先通过 git remote -v 找到指向主仓库的远程名，下文命令中的 base/ 全部替换为该远程名。
执行步骤
1. 拉取最新分支
git fetch base frontend_master v1.5.0
2. 生成 commit 状态列表
在仓库根目录执行（zsh/bash 均可）：
for sha in $(git log base/v1.5.0..base/frontend_master --no-merges --pretty=format:"%h"); do
info=$(git log -1 --pretty=format:"%an|%s" $sha)
msg=$(echo "$info" | cut -d'|' -f2)
issue=$(echo "$msg" | grep -oE "#[0-9]+" | tail -1)
st="未合入"
if [ -z "$issue" ]; then
st="无issue"
elif [ -n "$(git log base/v1.5.0 --no-merges --pretty=format:%h --grep="$issue" | head -1)" ]; then
st="已合入"
fi
echo "$st|$info"
done
注意：不要用 status 作为变量名，zsh 中它是只读变量。
3. 输出报告
只输出未合入的提交，格式：
## 本次发布计划（N 个）
| 作者 | 提交信息 |
| ---- | -------- |
| ... | ... |
- 标题带未合入个数，表格列
作者 | 提交信息，提交信息中保留 issue id 以便追溯。
- 已合入、无issue 的提交不输出，仅在存在异常（如无 issue id）时用一句话提醒。
如需追溯已合入提交在 v1.5.0 中的对应 commit：
git log base/v1.5.0 --no-merges --pretty=format:"%h %s" --grep="#<issue id>"
注意事项
- 全程只读操作，不要切换分支、不要修改工作区。
- issue id 取 commit msg 中最后一个
#数字（标题里可能引用多个 issue，约定尾部编号为准）。
--grep 匹配的是完整 commit message，若担心正文误匹配，可人工复核已合入条目。- 版本号分支名（
v1.5.0）和源分支名（frontend_master）按用户当次需求替换。
