场景
近期工作中，遇到了一些在项目版本管理上的问题。由于客户要求，在整个项目的开发中，项目需要频繁的交付部署，这其中涵盖Bug 修复及新的 Feature 开发。
我们拥有一套针对该项目的 CI/CD 环境资源，在一段时间开发后，我们发现时常会在部署 Bug 修复的时候，误带入了新的 Feature，或是在部署 Feature 的时候带入了别的还无需交付的 Feature，整个分支管理和版本管理都处于一种比较混乱的状态，这对于交付质量和开发体验都有很严重的负面影响。
通过分析我们项目现状以及可支配资源，给出了以下的建设性版本管理方案，以提高我们的版本管理效率，使工程结构清晰，增强可维护能力。
痛点
- 在项目开发中存在庞大的修改 Bug 的工作，如何更好的管理 Bug 版本？
- 项目中存在多个新功能需要开发，如何保证新功能不在错误的时间点提交？
- 如何便捷的做项目间的Bug 修复合并？
- 如何便捷的做项目间的Feature 合并？
版本控制模型
基础结构
由于目前阶段修改 Bug 的工作量巨大，占据总工作量近乎一半。考虑到我们支持持续集成及容器化部署，因此可虑阶段性的启用两套 CI 环境。 在此基础上，我们设定两条主分支，针对 Bug 和 Feature 进行分离的版本管理，使二者无交叉，仅在重要结点进行合并，从而保证版本的清晰与交付的准确。
业务背景
- 我们的项目都起源于同一个基础版工程 —— dev。
- oem-dev 和 oem-develop 为不同的两个项目。
版本管理流程
-
hotfix-ci-release 作为 bugfix 主分支，也是稳定的落地交付出包分支，运维每次仅需取用最新版本 docker image 进行部署, 该分支也作为测试验证 bug 的分支。
-
feature-ci-relese 作为 feature 的迭代的主分支, 每个独立的 feature 在完成提测时都将被合并到这个分支，以便测试进行验证。
-
修复完成后的 bug 可以在合适的节点合并到 feature 分支
-
新的 feature 在需要部署时合并到出包分支进行最终出包。
团队约定
-
申请两套完整的 ci 系统，一套用于单纯的 bugfix，bug 测试及落地环境部署出包，一套用于新 feature 开发与测试。
-
每个 commit 必须对应且仅对应一个 jira 版本号，以确保版本回溯和 commit 合并更加方便和精准。
-
同一项目中采用一致标准的分支命名规范。
a. 【name】-hotfix-release hotfix-release 分支 b. 【name】-feature-release feature-release 分支 c. 【name】/ fix-【jira id】 临时 fix 分支 d. 【name】/ feat-_【feature name】 独立功能开发分支 e. 【name】/【personId】 个人分支 f. 【name】/ merge-【jira id】 临时 merge 分支 g. 【name】/ feat-【feature name】-fix feature bugfix 分支 -
不同项目可采取不同分支管理或分仓库管理。
分支管理： a. 切换项目简单 b. 合并简单 c. 分支数量较多 分仓库管理： a. 项目独立 b. 分支清晰 c. 合并较复杂
结语
选择通过 branch 的合理规划，来解决版本的冲突与可能产生的矛盾。不采取以 git tag 为核心来做版本规划，是因为 tag 的可读性不够高，附带信息也不够丰富，检索效率也比较低。在重点节点上，我们依然可以标记 tag 来进行标注。
一个 commit 唯一对应一个 jira 版本，坚持这一点可以让我们后续的问题追溯及项目合并变得十分轻松。
上述所规划的版本管理模型适用性并不够高，不一定能适用其他场景，但重要的是提供一种设计思路，bug 和 feature 是我们日常工作中需要处理的两种主要类型事物，通过清晰的区分二者，来让我们的版本管理变得更加清晰和容易上手。
