首先直接给你吃个定心丸：标签（tag）是Git里的静态快照，一旦创建就固定指向某个特定提交，不会随分支更新而改变。所以你完全可以把release 0.3的标签打在master分支上，同时不用担心旧版本release 0.2的代码被篡改——只要tag 0.2存在，它对应的代码状态就永远是发布0.2时的样子。

一、核心疑问解答 #

你担心的“每次向master合并代码时旧版本内容被同步更新”是不会发生的。原因很简单：

• 分支（比如master）是动态指针，会随着新提交移动到最新的节点；
• 标签（比如tag 0.2）是静态快照，创建后就绑定到当时的提交哈希值，不管分支后续怎么更新，这个标签对应的代码永远不变。

哪怕你之后往master合并了100次代码，只要执行git checkout tag 0.2，就能精确回到release 0.2发布时的源代码状态。

二、发布release 0.3的具体操作步骤 #

假设你已经把所有要纳入release 0.3的代码（新功能、bug修复等）合并到了master分支，且master处于稳定可发布状态：

1. 拉取最新的master分支代码

   git checkout master
   git pull origin master
   

2. 创建release 0.3的标签
   推荐创建带注释的附注标签（更规范，便于追溯版本信息），也可以用轻量标签快速标记：

   # 附注标签（带版本说明）
   git tag -a 0.3 -m "Release version 0.3: 新增XX功能，修复XX bug"
   
   # 轻量标签（适合快速标记，无注释）
   git tag 0.3
   

3. 将标签推送到远程仓库（GitHub）
   注意：普通的git push不会推送标签，需要单独执行推送命令：

   # 推送单个标签
   git push origin 0.3
   
   # 如果有多个未推送的标签，可以批量推送
   git push origin --tags
   

4. 在GitHub上创建正式的Release（可选但推荐）
   登录GitHub仓库，找到「Releases」页面，点击「Draft a new release」：

   • 选择刚才推送的tag 0.3；
   • 填写版本标题（比如「Release 0.3」）和详细的发布说明；
   • 点击「Publish release」完成发布。

三、确保旧版本release 0.2代码保留的进阶方案 #

如果之后需要对release 0.2进行bug修复或维护，仅靠tag可能不够灵活（因为tag是只读的，不能直接在上面提交代码），你可以基于tag 0.2创建一个专门的维护分支：

# 检出tag 0.2的代码
git checkout tag 0.2

# 创建并切换到维护分支（命名建议用release/0.2这类规范格式）
git checkout -b release/0.2

# 将维护分支推送到远程仓库
git push origin release/0.2

之后你就可以在release/0.2分支上进行旧版本的修复工作，完全不会影响master分支和release 0.3的代码。

总结 #

• 直接给master打tag 0.3发布新版本，完全不会影响tag 0.2对应的旧代码；
• 标签是Git保留历史版本的核心方式，只要不手动删除tag，旧版本代码就永远存在；
• 如需维护旧版本，基于tag创建维护分支是行业标准的最佳实践。

内容的提问来源于stack exchange，提问作者bosari