版本控制（Version Control）是开源协作的基石，核心分为两大模块：代码分支管理策略（Git 工作流） + 版本号命名规范（语义化版本 SemVer），同时配套开源特有的发布、合并、回滚、Bug 修复流程。
一、基础前置：语义化版本 SemVer（所有开源通用版本命名规则）
几乎 99% 正规开源项目强制使用 Semantic Version 2.0，版本格式：
主版本.次版本.补丁版本 → X.Y.Z
三段号定义
X 主版本（Major）
不兼容的破坏性改动（Breaking Change）：API 大改、删除接口、架构重构、废弃旧功能。
例：
1.x→2.0.0，2.x 代码无法直接兼容 1.x 业务。Y 次版本（Minor）
向后兼容的新增功能，无破坏性改动，旧代码可无缝升级。
例：
2.1.0新增导出功能，2.0 项目升级无报错。Z 补丁版本（Patch）
向后兼容的Bug 修复，无新增功能，仅修复线上缺陷。
例：
2.1.1修复 2.1.0 内存泄漏问题。
扩展标签（开源常用）
预发布版：
2.2.0-alpha（内测）、2.2.0-beta（公测）、2.2.0-rc1（Release Candidate 候选发布）开发快照：
2.2.0-dev开发分支临时构建构建元数据：
2.1.0+build20260727，区分同版本不同打包构建
二、主流开源 Git 分支管理策略（版本控制核心流程）
开源项目协作人数多、外部贡献者（PR 提交者）不固定，衍生 4 套主流工作流，适用不同规模开源项目。
1. Git Flow（老牌大型开源：Redis、Nginx、Spring 全家桶）
最规范、流程最完整，适合有稳定版本发布周期、长期维护的企业级开源。
固定 5 类长期分支
main/master：生产稳定分支，永远只存放正式发布版本，禁止直接提交代码，每一次提交对应一个正式 Tag 版本。develop：开发主分支，所有新功能汇总于此，下一个正式版本的开发基线。feature/*：功能分支，从 develop 拉出，开发单个需求，完成后合并回 develop，合并后删除。release/*：发布分支，develop 功能全部完成后拉出，仅做测试、Bug 修复，不新增功能；修复完成后同时合并到 main 和 develop，并给 main 打版本 Tag。hotfix/*：紧急热修复分支，线上 main 出现严重故障时，直接从最新 main 拉出，修复后同时合并 main+develop，打补丁版本 Tag。
优缺点
✅ 版本边界清晰，正式环境、开发环境完全隔离，适合长期维护多版本（如同时维护 v1、v2 两个大版本）
❌ 分支过多，流程繁琐，小型开源项目显得冗余
2. GitHub Flow / GitLab Flow（轻量化开源：前端框架 Vue、React、各类工具库）
现代开源最流行策略，极简、适配持续发布（CI/CD），无固定 develop 分支，适合迭代快、持续发布的项目。
核心规则
仅一条长期稳定分支：
main（部分老项目叫 master），main 永远是可直接部署、可发布的稳定代码。所有改动新建临时分支：
feature/xxx、fix/xxx、docs/readme，从 main 拉出。外部贡献者通过 Pull Request(PR)/Merge Request(MR) 提交分支，经过代码评审（Code Review）、自动化测试通过后，合并进 main。
合并到 main 后，立即触发 CI 自动打包、发布新版本，打上对应版本 Tag。
无单独 release 分支：如需发布候选版，在 feature 分支打预发布标签即可。
GitLab Flow 补充（兼容多环境）
在 GitHub Flow 基础上增加 production、staging 环境分支，适配企业级开源多环境部署。
优缺点
✅ 流程极简，上手成本低，完美适配 GitHub/GitLab 协作，适合中小型开源、快速迭代工具库
❌ 不适合需要长期并行维护多个大版本的项目
3. Trunk Based Development（主干开发，云原生开源：K8s、Istio、Rust 语言）
云原生、高性能大型开源首选，追求高频合并、短生命周期分支，杜绝长期分支分叉。
核心规则
唯一主干
main/trunk，所有人基于主干开发。短生命周期分支：所有 feature 分支存活时间不超过 1 天，小改动直接本地提交推送；大功能用功能开关（Feature Flag） 隐藏未完成代码，允许合并进主干。
禁止长期分支：不维护 develop、release 长期分支，版本发布直接从主干打 Tag。
发布策略：
连续发布：主干稳定后直接发布小版本
多版本维护：若需要修复历史旧版本，从对应历史 Tag 拉出修复分支，修复后选择性合并回主干
优缺点
✅ 合并冲突极少，开发效率极高，适配云原生每日迭代、自动化发布
❌ 对自动化测试、CI 校验要求极高，测试不完善会导致主干频繁崩溃
4. OneFlow（Git Flow 轻量化改良，国内很多后端开源项目使用）
简化 Git Flow，保留多版本维护能力，砍掉冗余分支：
长期分支：
main（正式版）、develop（开发）临时分支：
feature、hotfix取消独立 release 分支：发布直接在 develop 上打 Tag，合并到 main
三、开源项目专属配套版本控制规则
1. Tag 版本标记规范
所有正式发布必须打轻量 Tag/Annotated Tag，格式严格遵循 SemVer：
# 创建正式版本标签
git tag -a v2.1.0 -m "Release v2.1.0: add export function"
git push origin v2.1.0
开源社区统一约定加前缀v，如v1.3.2，方便脚本批量识别版本。
2. 多版本并行维护策略（长期开源必备）
很多成熟开源需要同时维护多个主版本（例如 v1、v2、v3）：
为每个大版本创建长期分支：
v1-maintenance、v2-maintenance新功能只在最新大版本开发
历史旧版本仅接受安全补丁、严重 Bug 修复，不新增功能
修复完成后，旧版本分支打补丁版本 Tag（v2.1.2）
3. 外部贡献者版本协作规范（开源独有）
开源大量外部陌生人提交代码，版本流程约束：
贡献者 Fork 仓库，在自己仓库新建功能分支
向上游开源仓库提交 PR，关联 Issue（Bug / 需求工单）
维护者 Code Review，CI 自动化测试（单元测试、编译检查、代码规范）
通过后合并至开发 / 主干分支，统一纳入版本迭代
禁止外部贡献者直接推送代码到 main/develop 保护分支
4. 回滚与热修复版本流程
线上严重 Bug（hotfix）
从最新发布 Tag 拉出 hotfix 分支，修复后同时合并稳定分支 + 开发分支，升级补丁版本号（Z+1）。
合并错误回滚
若错误代码合并到主干，使用
git revert生成反向提交，保留版本历史（开源不允许直接删除历史 commit，合规性要求），发布补丁版本。
5. 版本发布周期管理
滚动发布：Trunk/GitHub Flow，主干稳定即发布，无固定周期（前端开源、工具类）
固定周期发布：Git Flow，每月 / 每季度统一打包发布（中间件、框架类开源）
LTS 长期支持版本：开源会标记 LTS 版本（如 v2.0 LTS），提供数年安全补丁，非 LTS 版本仅短期维护。
四、不同类型开源项目策略选型对照表
五、常见误区
混淆版本号：新增功能只升次版本 Y，不能直接升主版本 X；
长期 feature 分支不合并：极易产生海量代码冲突，违反主干开发 / GitHub Flow 核心思想；
直接在 main 分支提交代码：破坏稳定分支，开源项目都会配置分支保护禁止直接 push；
随意删除历史 Tag/Commit：开源需要完整变更历史用于安全审计、问题追溯。
原文链接
欢迎访问 小易撩挨踢