我们的项目发布是有版本的，比如说v1.0.0，v2.0.13之类的。此时我们有一个前端仓库和一个后端仓库，如何发布它们的版本并且保证它们两的版本是兼容的呢？想象一下这样的场景：用户下载了你的后端v1.2.0，却不知道应该搭配哪个前端版本，结果遭遇各种兼容性问题。良好的版本管理能避免这种混乱，让你的项目显得专业且易于使用。下面我们们细细的探究一下。
⌈优雅⌋开源
发布版本
先说如何发布版本，开发过程中，我们会频繁的创建commit，这是代码的历史记录点。当你已经把确定为该版本的代码最后一次push到了远程仓库，标志着我们发布版本的任务开始。那么就先会牵扯到版本该如何命名，版本号的结构：MAJOR.MINOR.PATCH
- 主版本号（MAJOR）：有不兼容的API修改
- 次版本号（MINOR）：向下兼容的功能新增
- 修订号（PATCH）：向下兼容的问题修正
不过我自己在这方面以及我看别人的开源项目在这方面的概念都比较模糊，并不都严格遵守。下面是一个具体开源版本发布的示例。
# 确定当前版本的代码并推送
git push origin main
# 创建带注释的标签
git tag -a v1.0.0 -m "发布新版本v1.0.0：第一个版本！"
# 推送标签到远程
git push origin v1.0.0
接下来就是进入远程仓库的网站，以github为例，进入仓库页面后点击Releases，接着Draft a new Release，选中目标版本的tag并对当前版本信息做详细描述（建议有自己的一套模板），即为发布成功！
元仓库
那么我们说回前后端版本兼容的情况，开发者面对我们的前端和后端的仓库的多样的版本，并不清楚应该将哪两个版本相互匹配，而在README中指明，显然不是一个有强指引效果的⌈优雅⌋的方案。而使用元仓库，就能很好的将两个仓库关联起来，它不包含实际业务代码，而是提供项目的全景视图和导航功能。
现在，我们以Auth-Matrix为例。在已经有了前后端仓库并且发布了相互兼容的版本的前提下，比如auth-matrix-backend v1.0.0以及auth-matrix-frontend v1.0.1。
# 我们先初始化元仓库
mkdir auth-matrix
cd auth-matrix
git init
# 接着添加前后端仓库到元仓库
# 或者通过ssh方式，都行
git submodule add https://github.com/thirty30ww/auth-matrix-backend.git
git submodule add https://github.com/thirty30ww/auth-matrix-frontend.git
# 拉取所有子模块最新代码
git submodule update --init --remote
# 选择兼容的要发布的版本
cd ./backend
git checkout v1.0.0
cd ../frontend
git checkout v1.0.1
# 6. 提交版本锁定
git add .
git commit -m "发布我的第一个前后端兼容版本！"
# 7. 创建元仓库版本标签
git tag -a v1.0.0 -m "发布新版本v1.0.0：第一个版本！"
# 8. 推送更新
git push origin v1.0.0
这样就有了一个前后端兼容的元仓库tag了，和上面的步骤一样release
总结
- 从元仓库的README快速掌握项目全貌
- 通过GitHub Releases获取经过验证的兼容版本组合
- 一键克隆即可获得完美匹配的前后端代码
这种设计既保持了组件独立性，又解决了版本兼容的痛点，让开源协作变得简单而优雅。