企业官网建设流程全解析

• 人工智能
• MCP 服务
• MCP Clients

本文基于 release-tagger.md 编写，面向 mcp-go（GitHub 加速计划 / mcp / mcp-go）项目维护者。这是一份可落地的 Release 打标签工作流：通过分析仓库提交历史，依据 Semantic Versioning（语义化版本）规则计算新版本号，创建带详细说明的 annotated tag，并推送发布。读完本文，你将掌握从git fetch --tags到git push origin vX.Y.Z的完整发布流程，并理解 mcp-go 这类 Go 库在版本决策上的特殊考量。

一、为什么需要规范化的版本标签流程

mcp-go 是一个 Go 语言实现的 Model Context Protocol（MCP）SDK，它同时面向两类使用者：作为库被go get github.com/mark3labs/mcp-go引入（见 README.md 的 Installation 章节），也作为服务端/客户端框架支撑上层应用。库的消费者依赖 Go module 版本解析，而 Go modules 的版本信息完全来源于 Git tag——这意味着 tag 命名与发布时机直接决定了下游用户能否平滑升级。

规范化的 Release 流程能带来三个确定性：

• 版本号可预期：严格遵守语义化版本，用户能根据MAJOR.MINOR.PATCH推断升级风险；
• 发布可追溯：annotated tag 携带作者、时间戳与变更说明，与提交历史一一对应；
• 过程可重复：固定的命令序列（fetch → 分析 → 计算 → 起草 → 打签 → 推送）避免人工遗漏。

二、发布前置：理解 mcp-go 的版本现状

在动手打标签前，先确认仓库当前状态。以本仓库为例（镜像环境仅保留最近一次 tag，实际维护仓库请以git tag输出为准）：

# 查看当前所有 tag，按版本号排序后看最新的几个 git tag -l | sort -V | tail -15

当前 mcp-go 最新 tag 为v1.1.1，且位于main分支。项目根目录的 go.mod 声明模块为github.com/mark3labs/mcp-go，Go 版本要求为1.25.5——这意味着任何涉及 Go 版本下限提升的改动都应当视为潜在的兼容性风险点，在版本决策时需格外谨慎。

mcp-go 还维护着一组与 Release 版本并行的协议版本常量，定义于 mcp/version.go：

• ProtocolVersion20260728（最新，无状态协议核心）、ProtocolVersion20251125、ProtocolVersion20250618、ProtocolVersion20250326、ProtocolVersion20241105（原始修订版）；
• LATEST_PROTOCOL_VERSION = ProtocolVersion20260728标识 SDK 支持的最新 MCP 协议版本。

可以推断：当仓库引入新协议版本支持（如新增一个ProtocolVersion20XX常量并进入ValidProtocolVersions）时，属于新增能力，倾向 MINOR 增量；而移除某个旧协议或破坏既有 API 兼容性，则必须触发 MAJOR 评估。这是本仓库发布决策中"Go 项目特有"的判断维度之一。

三、发布八步：从拉取远端标签到推送新版本

第 1 步：拉取远端标签

发布前必须先同步远端标签，避免本地与远端版本记录不一致导致冲突：

git fetch --tags origin

这是整个流程的强制前置。若省略此步，可能在计算"最新版本"时基于过期的本地数据，甚至在git push时因 tag 已存在于远端而失败。

第 2 步：确定当前最新版本

git tag -l | sort -V | tail -5

sort -V按语义化版本自然排序（v1.9.0会正确排在v1.10.0之前，而非按字典序错排），tail -5展示最新的五个 tag，作为增量计算的基准。设最新 tag 为<latest-tag>，下文所有增量分析均以它为边界。

第 3 步：分析自上个 tag 以来的变更

三条命令从三个粒度观察变更集：

# 1) 提交列表：快速浏览都有哪些提交 git log <latest-tag>..HEAD --oneline # 2) 文件统计：看哪些路径发生了多少改动 git diff <latest-tag>..HEAD --stat # 3) 变更文件清单：精确到文件名，便于识别关键模块 git diff <latest-tag>..HEAD --name-only

以本仓库为例，若最新 tag 为v1.1.1，则使用git log v1.1.1..HEAD --oneline查看其后的提交。三条命令配合使用：--oneline快速浏览提交主题，--stat评估改动规模，--name-only定位具体波及文件（尤其要关注是否触及导出 API）。

第 4 步：依据 Semantic Versioning 确定增量级别

这是整个流程的核心决策环节。语义化版本MAJOR.MINOR.PATCH的增量规则：

mcp-go 采用的 Conventional Commits 提交规范（见 .kit/prompts/commit-push.md：类型为feat、fix、refactor、chore、docs、test、perf、build，格式为<type>(<scope>): <summary>）使提交前缀成为版本判断的直接信号：

• 提交含feat:/feature:→MINOR（新功能）
• 提交含fix:/bugfix:→PATCH（缺陷修复）
• 提交含breaking:或BREAKING CHANGE:→MAJOR（破坏性变更）
• 变更触及pkg/或公开接口（Go 项目中即导出函数、类型、接口的签名变化）→MAJOR
• 新增命令、flag 或功能 →MINOR
• 仅文档变更（docs:）→PATCH，或直接跳过本次发布

第 5 步：计算新版本号

确定增量后，按语义化版本规则递增对应段位，并将更低段位全部归零：

• 上版本v1.1.1+ MAJOR →v2.0.0
• 上版本v1.1.1+ MINOR →v1.2.0
• 上版本v1.1.1+ PATCH →v1.1.2

第 6 步：起草 Tag 消息

从提交列表提炼关键变更，按类型分组（Features / Fixes / Breaking Changes），保持简洁但有信息量。这一步建议先起草给用户过目，再执行打签命令。

第 7 步：创建带注释的 Tag

git tag -a vX.Y.Z -m "vX.Y.Z - <summary>\n\n<detailed list>"

必须使用-a（annotated tag），它会记录打签者、时间戳与完整消息，并独立于 commit 参与对象库存储——与轻量 tag（lightweight tag，仅指向某 commit 的引用）不同，annotated tag 是"可追溯的发布记录"，适合作为 Release 标志。

第 8 步：推送 Tag

git push origin vX.Y.Z

指定 tag 名推送而非git push --tags批量推送，确保只发布确认过的版本。推送成功后，该 tag 即可被go get github.com/mark3labs/mcp-go@vX.Y.Z或go get ...@latest解析使用。

四、发布准则与注意事项

原文档明确了以下必须遵守的准则，结合 mcp-go 仓库可进一步解读：

1. 先拉远端标签，避免冲突：git fetch --tags origin是每一步的前提；
2. 使用 annotated tag 并撰写描述性消息：轻量 tag 无法承载 Release Notes；
3. 严格遵循 semver，存疑时保守：当某个变更"像修复也像新功能"时，倾向 PATCH（保守）而非 MINOR，避免给下游造成不必要的升级压力；
4. Go 项目的特殊考量：变更触及pkg/或导出 API 时需格外谨慎——对 mcp-go 而言，mcp/ 目录下的types.go、tools.go、prompts.go、resources.go、tasks.go、mrtr.go等文件定义了对外暴露的类型与接口，任何签名变更都可能破坏下游编译；
5. 若无变更则跳过发布：git log <latest-tag>..HEAD为空（或仅有无意义的 chore 改动）时，直接建议跳过本次 Release，不为了发版而发版；
6. Tag 消息正文包含提交摘要：让 Release Notes 可直接从 tag 消息生成。

五、Tag 消息格式示例

原文档给出了可直接套用的消息模板。以一次"修复 + 改进"型发布为例：

v0.30.1 - Bug fixes for model handling and UI improvements Fixes: - Properly handle think tags from Qwen/DeepSeek models - Handle custom provider model persistence and bare model names Improvements: - UI style refactoring and cleanup

结构要点：第一行vX.Y.Z - <一句话摘要>；正文按类型分组（Fixes / Improvements / Features / Breaking Changes），每条以短横线列表呈现，只描述"做了什么、解决了什么"，不展开实现细节。

六、发布前的最后一道闸门：人工确认

整个流程在创建 tag 与推送之前必须暂停：将计算出的新版本号与起草的 tag 消息提交给用户确认，得到明确同意后再执行：

git tag -a vX.Y.Z -m "<确认后的消息>" git push origin vX.Y.Z

这道确认闸门防止两类事故：一是版本号误判（如把破坏性变更标成了 PATCH，tag 一旦推送并被人 fetch，很难无声撤回）；二是 tag 消息信息失真（发布说明与真实提交不符，影响下游用户评估升级风险）。对 mcp-go 这类被go get消费的库，一次错误的版本决策会直接影响所有依赖者的升级路径，因此"先确认、后推送"不是可选项，而是发布纪律。

七、发布后的收尾检查

推送完成后建议执行一次快速校验，确认发布闭环：

# 确认 tag 已出现在远端 git ls-remote --tags origin | grep vX.Y.Z # 或本地验证 tag 指向的提交 git show vX.Y.Z --stat

至此，一次完整的 mcp-go Release 打标签流程结束：从拉取远端标签、分析提交历史、依据 semver 计算版本、起草并确认消息，到创建 annotated tag 并推送，每一步都有明确的命令与判断依据。将本流程与 .kit/prompts/commit-push.md 的 Conventional Commits 提交规范配合使用，即可在 mcp-go 仓库中建立起"规范提交 → 版本判定 → 标签发布"的完整发布链路。

• 人工智能
• MCP 服务
• MCP Clients