Improve Release Workflow: Add Tagging on Master/Main Branch

[platonai]

1. tag 应该打在哪个分支上？

最佳实践：tag 应该打在 main（或 master）分支上。

• 原因：main 分支代表的是“生产环境”或“正式发布”的代码。只有 main 分支的代码才是经过充分测试、可以安全发布的版本。
• 流程：通常开发在 dev 或 feature 分支进行，合并到 main 后，main 上的 commit 就是发布版本，这时打 tag，标记这个 commit 为一个 release 版本。

示例流程：

1. 在 dev 分支开发，完成后合并到 main。
2. 在 main 分支上确认无误，打 tag（如 v1.0.0）。
3. 部署/发布。

---

2. 是否有必要单独开 release 分支？

视团队规模和需求而定：

适合小型项目/团队

• 不需要单独 release 分支。
• dev → main，main 上打 tag 即可。

适合中大型项目/团队

• 建议有 release 分支，尤其是多人协作、需要预发布、bugfix、热修复等场景。
• 典型流程：
  1. dev 分支开发。
  2. 功能冻结后，从 dev 分支切 release/x.y.z 分支。
  3. 在 release 分支上只做 bugfix、文档、版本号等准备工作。
  4. release 分支合并到 main（发布），在 main 上打 tag。
  5. release 分支的 bugfix 也要合并回 dev。
  6. release 分支合并到 main 后可以删除。

优点：

• 发布准备和开发解耦，开发可以继续在 dev 上进行。
• 可以多版本并行维护（如 hotfix/1.0.1, release/2.0.0）。

---

3. 典型分支模型参考

• Git Flow：有 feature、develop、release、hotfix、main 分支，适合复杂项目。
• GitHub Flow：只有 main 和 feature 分支，适合简单项目。

---

4. 结论

• tag 应该打在 main 分支上，因为 main 代表正式发布的代码。
• 是否需要 release 分支，取决于项目复杂度和团队协作需求。小项目可以不用，复杂项目建议用。