从MyJUnit反思Java项目的工程实践(版本控制篇)

从 MyJUnit 反思Java项目的工程实践(版本控制篇)

参考资料

1. deepseek
2. github copilot
3. CSDN-Git代码管理工作流程：GitFlow详解
4. Conventional Commits手册
5. 封面来自 qwen-image

遵循 git flow 分支管理模型

Git Flow 是一种围绕项目发布的核心分支模型, 它规定了不同的开发任务应当存放在不同的分支上, 使得开发更加结构化.

Git FLow 的核心是两种主分支和三种辅助分支:

1. 主分支(master/main):
   • 用途: 用于存放稳定, 可以随时部署到生产环境的代码. MyJUnit 的每一个正式发布版本都应当在该分支打上Tag
   • 规则:
     • 仅允许通过 release 或 hotfix 分支合并代码
     • 每次合并后必须打上语义化版本标签(如v1.0.0)
2. 开发分支(develop):
   • 用途: 作为开发集成基线，所有新功能、修复均合并至此分支。
   • 规则:
     • 是创建其他临时分支（如 feature、release）的起点。
     • 必须始终保持最新状态, 定期与主分支同步
3. 功能分支 (feature/)：从 develop 分支创建，用于开发新功能(例如 feature/add-parameterized-tests)。开发完成后合并回 develop 分支。
4. 发布分支(release/): 当 develop 分支积累了足够的新功能并准备发布时，从 develop 创建（例如 release/v1.1.0）。此分支仅用于修复 Bug、生成文档等发布准备工作，完成后分别合并到 master (打 Tag) 和 develop 分支。
5. 热修复分支 (hotfix/)：从 master 分支创建，用于紧急修复生产环境中的 Bug (例如 hotfix/fix-npe-in-assertion)。修复后需同时合并回 master (打 Tag) 和 develop 分支。

Conventional Commits 提交规范（详细实践）

Conventional Commits 规范是一种轻量级的约定，它通过一套简单的规则来创建清晰的提交历史

commit 提交信息结构

规范约定 commit 的结构如下所示:

原文
<type>[optional scope]: <description>[optional body][optional footer(s)]

译文:
<类型>[可选 范围]: <描述>[可选 正文][可选 脚注]

• type (类型，必需)：表明提交的性质。常用类型包括：
  • feat：新增功能（对应 MINOR 版本号递增）。
  • fix：修复 Bug（对应 PATCH 版本号递增）。
  • docs：文档更新。
  • style：代码格式调整（不影响代码逻辑）。
  • refactor：代码重构（既非新增功能，也非修复 Bug）。
  • test：增加或修正测试用例。
  • chore：构建过程或辅助工具的变动。
• scope (范围，可选)：说明提交影响的部分或模块。例如 fix(assertions), docs(readme)。
• description (描述，必需)：对本次变更的简短描述。
• body (正文，可选)：提供更详细的变更动机或与之前行为的对比。
• footer (脚注，可选)：通常用于记录破坏性变更 (BREAKING CHANGE) 或关闭 Issue（例如 Closes #123）。

在 MyJUnit 项目中的操作示例

• 新增一个断言方法：

  feat(assertions): add `assertNotNull` method
  

• 修复 Before 注解的逻辑：

  fix(core): execute @Before methods in correct order
  

• 为项目添加 CI 配置：

  chore(ci): add GitHub Actions workflow for running tests
  

• 修复了一个破坏性变更（改变了公共 API）：

  refactor(core)!: rename TestRunner to TestEngineBREAKING CHANGE: The public class `TestRunner` has been renamed to `TestEngine` for better semantics.
  

  （注意!用于提醒破坏性变更）