laoyang/SyncCalendar
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

补打历史版本 tag：v0.0.1 ~ v0.0.8（版本线完整化） #1

New Issue
Closed
opened 2026-10-28 15:37:13 +00:00 by laoyang · 1 comment
laoyang commented 2026-10-28 15:37:13 +00:00
Owner
Copy Link
Copy Source

现象 / 诉求

远端仓库此前只有 v0.0.9、v0.1.0 两个 tag，早于 0.0.9 的版本没有任何标记，
既无法从仓库直接看出"某个版本对应哪段代码"，也无法按版本回滚 / 比对。
用户要求：把 v0.0.1 ~ v0.0.8 也补上 tag，让版本线从首次发布起就完整。

关键难点（决定 tag 不能随便打）

  1. tag 必须指向「该版本交付物最终状态」的提交，不是「改版本号那次提交」。
    多个版本在版本号 bump 之后还有功能 / 修复提交，它们都进了同一个上架包。若打在 bump 提交上，
    tag 就会漏掉真实交付内容。
  2. 0.0.3 / 0.0.4 / 0.0.5 从未单独上架（发布说明原文：「0.0.3 / 0.0.4 / 0.0.5 均未单独上架，
    其内容全部包含在 0.0.6 中」）。tag 消息必须如实标注，不能写成"已发布"。
  3. 0.0.1 提审被驳回、未上架（审核指南 7.17 权限提前弹窗），也需如实标注。
  4. v1.0.0 是模板默认值（bbb3ec5 / c04a9a2 的 versionName），不是真实发布，不得打 tag。

做法

以 上架更新说明-*.md 里逐版本列出的提交清单为准（不是看提交信息），
反查每个上架包的最终状态，逐个定位：

tag 目标提交 定位依据
v0.0.1 76d8288 0.0.1 段最后提交；提审被驳回，未上架
v0.0.2 165740f 0.0.2 段最后提交；首个正式上架版本
v0.0.3 8b5519b 发布说明「0.0.3 对应提交」最后一项；未单独上架
v0.0.4 32162b8 发布说明「0.0.4 = d0b8720 + b83ce83 + 32162b8」；未单独上架
v0.0.5 cd24012 发布说明 0.0.5 五项最后一项；未单独上架
v0.0.6 da0249d 0.0.6 上架包于当日 08:50 打出，da0249d 为 08:30
v0.0.7 ed26da8 唯一提交
v0.0.8 942f71b 发布说明「0.0.8 最终版」三项收尾的最后一项

全部用 annotated tag（带版本号 / 交付状态 / 内容摘要），并推送到远端。

验收标准

  • git ls-remote --tags 能看到 v0.0.1 ~ v0.1.0 共 10 个 tag，且都是 annotated（有 ^{} 行）。
  • 相邻 tag 之间无遗漏、无重叠：git log --oneline v0.0.8..v0.0.9 只剩 2f124ea、c711cdb。
  • 每个 tag 的 tag 消息里能看清「versionName / versionCode / 是否单独上架」。
  • 不出现 v1.0.0。
## 现象 / 诉求 远端仓库此前只有 `v0.0.9`、`v0.1.0` 两个 tag，早于 0.0.9 的版本没有任何标记， 既无法从仓库直接看出"某个版本对应哪段代码"，也无法按版本回滚 / 比对。 用户要求：**把 v0.0.1 ~ v0.0.8 也补上 tag，让版本线从首次发布起就完整。** ## 关键难点（决定 tag 不能随便打） 1. **tag 必须指向「该版本交付物最终状态」的提交，不是「改版本号那次提交」。** 多个版本在版本号 bump 之后还有功能 / 修复提交，它们都进了同一个上架包。若打在 bump 提交上， tag 就会漏掉真实交付内容。 2. **0.0.3 / 0.0.4 / 0.0.5 从未单独上架**（发布说明原文：「0.0.3 / 0.0.4 / 0.0.5 均未单独上架， 其内容全部包含在 0.0.6 中」）。tag 消息必须如实标注，不能写成"已发布"。 3. **0.0.1 提审被驳回、未上架**（审核指南 7.17 权限提前弹窗），也需如实标注。 4. `v1.0.0` 是模板默认值（`bbb3ec5` / `c04a9a2` 的 `versionName`），**不是真实发布，不得打 tag**。 ## 做法 以 `上架更新说明-*.md` 里逐版本列出的提交清单为准（不是看提交信息）， 反查每个上架包的最终状态，逐个定位： | tag | 目标提交 | 定位依据 | |---|---|---| | v0.0.1 | `76d8288` | 0.0.1 段最后提交；提审被驳回，未上架 | | v0.0.2 | `165740f` | 0.0.2 段最后提交；**首个正式上架版本** | | v0.0.3 | `8b5519b` | 发布说明「0.0.3 对应提交」最后一项；未单独上架 | | v0.0.4 | `32162b8` | 发布说明「0.0.4 = d0b8720 + b83ce83 + 32162b8」；未单独上架 | | v0.0.5 | `cd24012` | 发布说明 0.0.5 五项最后一项；未单独上架 | | v0.0.6 | `da0249d` | 0.0.6 上架包于当日 08:50 打出，`da0249d` 为 08:30 | | v0.0.7 | `ed26da8` | 唯一提交 | | v0.0.8 | `942f71b` | 发布说明「0.0.8 最终版」三项收尾的最后一项 | 全部用 **annotated tag**（带版本号 / 交付状态 / 内容摘要），并推送到远端。 ## 验收标准 - `git ls-remote --tags` 能看到 v0.0.1 ~ v0.1.0 共 10 个 tag，且都是 annotated（有 `^{}` 行）。 - 相邻 tag 之间无遗漏、无重叠：`git log --oneline v0.0.8..v0.0.9` 只剩 `2f124ea`、`c711cdb`。 - 每个 tag 的 tag 消息里能看清「versionName / versionCode / 是否单独上架」。 - 不出现 `v1.0.0`。
laoyang commented 2026-10-28 15:40:44 +00:00
Author
Owner
Copy Link
Copy Source

已完成并验证

最终 tag 位置

按 versionName 切段 + 上架更新说明-*.md 的 commit 清单交叉校准，8 个 tag 全部指向
该版本交付物的最终状态：

tag 提交 上架状态
v0.0.1 76d8288 未上架（提审驳回：审核指南 7.17 权限提前弹窗）
v0.0.2 165740f 首个正式上架版本
v0.0.3 8b5519b 未单独上架（并入 0.0.6）
v0.0.4 32162b8 未单独上架（并入 0.0.6）
v0.0.5 cd24012 未单独上架（并入 0.0.6）
v0.0.6 da0249d 已上架
v0.0.7 ed26da8 已上架
v0.0.8 942f71b 已上架

过程中修正的两个判断错误

  1. 0.0.6 起初想取段末 68329c5（该 versionCode 段的最后一次提交）——错。
    0.0.6 的上架包是 10-10 08:50 打的，而 2b29f19（12:49 后台同步重构）和
    68329c5（10-11 README）都在其后，没有打进这个包。
    ⇒ tag 只能是 da0249d；后台重构实际属于 0.0.7 的交付内容。
    判据是发布说明里的打包时间戳，不是 git 分段边界。
  2. 0.0.8 起初想取段末 2f124ea —— 那已经是 0.0.9 待发版的工作。
    发布说明「0.0.8 最终版」三项收尾的最后一项是 942f71b（包于 10-16 19:36 打出）。

验证结果

$ git ls-remote --tags origin | wc -l
20                              # 10 个 tag × (tag 对象 + ^{} 解引用) ⇒ 全 annotated
$ git ls-remote --tags origin | grep -vc '\^{}'
10
$ git rev-list --left-right --count origin/master...master
0	0

区间自检（相邻 tag 之间应恰好是该版本的实际增量，无重叠无遗漏）：

  • v0.0.8..v0.0.9 → 只剩 2f124ea（镜像全选）、c711cdb（版本号）✓
  • v0.0.9..v0.1.0 → 7 个：颜色修复之后的全部 0.1.0 内容 ✓
  • v0.1.0..master → 只有 63b1a75（README）✓

v1.0.0 未创建（模板默认值，非真实发布）。

每个 tag 的注释都写明了

versionName / versionCode / 是否单独上架 / 本版主要内容摘要。
0.0.6 的注释额外标注了 2b29f19 不在本 tag 范围内及原因，避免以后误判。

## 已完成并验证 ### 最终 tag 位置 按 `versionName` 切段 + `上架更新说明-*.md` 的 commit 清单交叉校准，8 个 tag 全部指向 **该版本交付物的最终状态**： | tag | 提交 | 上架状态 | |---|---|---| | v0.0.1 | `76d8288` | 未上架（提审驳回：审核指南 7.17 权限提前弹窗） | | v0.0.2 | `165740f` | **首个正式上架版本** | | v0.0.3 | `8b5519b` | 未单独上架（并入 0.0.6） | | v0.0.4 | `32162b8` | 未单独上架（并入 0.0.6） | | v0.0.5 | `cd24012` | 未单独上架（并入 0.0.6） | | v0.0.6 | `da0249d` | 已上架 | | v0.0.7 | `ed26da8` | 已上架 | | v0.0.8 | `942f71b` | 已上架 | ### 过程中修正的两个判断错误 1. **0.0.6 起初想取段末 `68329c5`**（该 versionCode 段的最后一次提交）——错。 0.0.6 的上架包是 10-10 **08:50** 打的，而 `2b29f19`（12:49 后台同步重构）和 `68329c5`（10-11 README）都在其后，**没有打进这个包**。 ⇒ tag 只能是 `da0249d`；后台重构实际属于 0.0.7 的交付内容。 **判据是发布说明里的打包时间戳，不是 git 分段边界。** 2. **0.0.8 起初想取段末 `2f124ea`** —— 那已经是 0.0.9 待发版的工作。 发布说明「0.0.8 最终版」三项收尾的最后一项是 `942f71b`（包于 10-16 19:36 打出）。 ### 验证结果 ``` $ git ls-remote --tags origin | wc -l 20 # 10 个 tag × (tag 对象 + ^{} 解引用) ⇒ 全 annotated $ git ls-remote --tags origin | grep -vc '\^{}' 10 $ git rev-list --left-right --count origin/master...master 0 0 ``` 区间自检（相邻 tag 之间应恰好是该版本的实际增量，无重叠无遗漏）： - `v0.0.8..v0.0.9` → 只剩 `2f124ea`（镜像全选）、`c711cdb`（版本号）✓ - `v0.0.9..v0.1.0` → 7 个：颜色修复之后的全部 0.1.0 内容 ✓ - `v0.1.0..master` → 只有 `63b1a75`（README）✓ `v1.0.0` 未创建（模板默认值，非真实发布）。 ### 每个 tag 的注释都写明了 `versionName` / `versionCode` / **是否单独上架** / 本版主要内容摘要。 0.0.6 的注释额外标注了 `2b29f19` 不在本 tag 范围内及原因，避免以后误判。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
laoyang (老杨)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: laoyang/SyncCalendar#1