Git版本控制

版本号管理

语义化版本号

版本号通常由三个部分组成：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH）

• 主版本号：当进行不兼容的API修改时
• 次版本号：当添加向下兼容的功能时
• 修订号：当进行向下兼容的问题修复时

版本号规范

1. 正式版本号格式：X.Y.Z

   • X：主版本号
   • Y：次版本号
   • Z：修订号

2. 先行版本号

   • Alpha版本：1.0.0-alpha.1
   • Beta版本：1.0.0-beta.1
   • RC版本：1.0.0-rc.1

3. 版本号递增规则

   • 主版本号：重大更新，不兼容旧版
   • 次版本号：新功能，兼容旧版
   • 修订号：bug修复，兼容旧版

Tag管理

Tag的作用

• 标记重要的版本节点
• 便于版本回溯和管理
• 记录版本发布历史

Tag类型

1. 轻量标签

   • 仅包含提交信息
   • 适用于临时标记

2. 附注标签

   • 包含完整的标签信息
   • 推荐用于正式发布

Tag操作指南

1. 创建标签

## 创建轻量标签
git tag v1.0.0

## 创建附注标签
git tag -a v1.0.0 -m "版本1.0.0发布"

2. 推送标签

## 推送单个标签
git push origin v1.0.0

## 推送所有标签
git push origin --tags

3. 删除标签

## 删除本地标签
git tag -d v1.0.0

## 删除远程标签
git push origin :refs/tags/v1.0.0

版本发布流程（精简版）

1. 从 develop 切 release/1.2.0，只修 bug 不加功能。
2. 测试通过后合到 main，打附注标签 git tag -a v1.2.0 -m "发布说明"。
3. main 的标签推送到远程：git push origin v1.2.0。
4. 把 release 合回 develop，删掉 release 分支。

最佳实践（精简版）

• 正式版本用附注标签：git tag -a v1.0.0 -m "说明"，轻量标签只用于本地临时标记。
• 标签命名：v + 语义化版本（v1.2.3），和 package.json / pubspec.yaml 里的版本号保持一致。
• 删远程标签：git push origin :refs/tags/v1.0.0（或 --delete），本地删了远程还在是常见坑。

常见问题

本地删了标签，远程还在

git tag -d 只删本地。远程要用 git push origin :refs/tags/<tag>，否则下次 git fetch 又会拉回来。

总结

版本号是给人看的契约：MAJOR 升了意味着可能不兼容，MINOR 是加功能，PATCH 是修 bug。标签是给机器看的锚点：每个正式发布打一个附注标签，出了问题 git checkout v1.2.2 就能回到现场。

实战案例：这个博客仓库的版本管理

这个博客（ygking-blog）本身就是个真实案例。它的 Git 历史很有代表性：

1. 分支就是 master。个人博客不需要 git-flow，没有 develop，没有 release 分支——所有提交直接上 master，靠 Cloudflare Pages 自动部署。小项目别学大厂那套分支模型，master + 自动化部署就是最优解。
2. commit 信息是”给未来的自己看的”。我在这个仓库的提交比如 feat: refresh profile and switch to Cloudflare Pages，一看就知道干了什么。反面例子是 update、fix、123——三个月后你自己都看不懂。我的铁律：动词开头（feat/fix/docs/refactor），一句话说清”改了什么”。
3. CHANGELOG.md 是手写的。这个仓库根目录有个 CHANGELOG，每次发版手动记一笔。有人觉得”git log 就能看”，但 log 是给机器看的流水账，CHANGELOG 是给人看的”人话版”——用户只关心”新增了什么、修了什么”。

还有个教训：这个仓库之前混进过 .obsidian/ 配置目录（编辑器配置），后来才用 .gitignore 排除。.gitignore 要在第一次提交前写好，等垃圾进仓库再删，历史记录里永远有它，git filter-branch 洗历史的酸爽你不会想体验第二次。