AIP智能体平台

# Git版本管理规范

# 概述

定义Git版本管理的规范，包括主分支管理规范、分支管理规范、分支合并规范等。

# 你将获取

  • 主分支用于发布稳定版本，禁止直接在主分支上进行开发。
  • 使用分支进行开发，每个功能或任务创建一个独立的分支。
  • 使用合并或变基操作将功能分支合并到开发分支。
  • 在发布稳定版本时，创建一个标签来标识版本号。
  • 使用远程仓库进行代码备份和协作开发。
  • 提交前进行代码审查，确保代码质量和规范性。
  • 提交前进行本地测试，确保代码的功能和逻辑正确。
  • 提交前进行代码格式化，保持代码风格的一致性。
  • 提交时编写有意义的提交信息，描述本次提交的目的和内容。
  • 避免一次提交包含过多的修改，保持提交的原子性。

# 管理规范

# 环境管理

如果多城市同一个项目，应起另一个配置包,配置版本号类似 如同一环境下面又分多个环境，如开发环境，分为现场开发环境和团队内部开发环境，则在后面添加后缀，如dev-xiangchange,dev-neibu

序号 说明 代表 全称 维护人员 备注
1 示例环境 demo
2 本地开发环境 local Local Development environment
3 开发环境 dev Local Development environment
4 系统内部功能测试环境 fat Feature Acceptance Test environment
5 用户验证测试环境 uat User Acceptance Test environment
6 压力测试环境 lpt Load and Performance Test environment
7 生产环境 pro Production environment 运维 略

# 工程版本管理

此处参考了 dubbo 的版本管理,只是暂定如此，后期会根据过程中不断调整，但是大体的管理方向是如此。后期不断调整的原因是根据团队的情况， 看合适哪种合作方式做调整或者现实情况,有些情况之下，可能以下的版本管理根本不需要也有可能。

序号 工程版本 说明 备注
1 Alpha 是内部测试版,一般不向外部发布,会有很多 Bug.一般只有测试人员使用。
2 Beta 也是测试版，这个阶段的版本会一直加入新的功能。在 Alpha 版之后推出。
3 RC (Release 　 Candidate) 顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC 版不会再加入新的功能了，主要着重于除错。
4 GA General Availability,正式发布的版本，在国外都是用 GA 来说明 release 版本的。 .

新功能的开发 和 稳定性的提高 对产品都很重要。但是添加新功能会影响稳定性，使用如下的版本开发模式来保障两者。

  • BugFix 版本：低版本，比如 2.4.x。是 GA 版本，线上使用的版本，只会 BugFix，升级第三位版本号。
  • 新功能版本：高版本，比如 2.5.x。加新功能的版本，会给对新功能有需求的应用试用。
  • 2.5.x 的新功能基本稳定后，进入 2.5.x 试用阶段。找足够多的应用试用 2.5.x 版本。

在 2.5.x 够稳定后：

  • 2.5.x 成为 GA 版本，只 BugFix，推广使用此版本。如何可行，可以推进应用在期望的时间点内升级到 GA 版本。
  • 2.4.x 不再开发，应用碰到 Bug 让直接升级。（这个称为“夕阳条款”）
  • 从 2.5.x 拉成分支 2.6.0，作为新功能开发版本。

优势

  • 保证 GA 版本是稳定的！因为：只会作 BugFix，成为 GA 版本前有试用阶段
  • 新功能可以在高版本中快速响应，并让应用能试用新功能。
  • 不会版本过多，导致开发和维护成本剧增

用户要配合的职责

  • 由于开发只会 BugFix GA 版本，所以用户需要积极跟进升级到 GA 版本，以 Fix 发现的问题。
  • 定期升级版本给用户带来了不安。这是一个假命题，说明如下：
  • GA 经过一个试用阶段保持稳定。
  • GA 版本有 Bug 会火速 Fix
  • 相对出问题才升级到 GA 版本（可能跨了多个版本）定期升级平摊风险（类似小步快跑）。经历过周期长的大项目的同学会有这样的经历，
  • 三方库版本长时间不升级，结果出了问题不得不升级到新版本（跨了多个版本）风险巨大。

# 开发规范

  1. 【强制】开发人员每天签到后必须从 Git 服务器上获得当前最新版本。
  2. 【强制】结束工作后必须将代码提交至 Git 服务器并保证代码可编译。
    说明：每个模块需本地测试通过 ，确定没有问题，再合并至测试基线 ，开发基线建议提交时添加注释说明，并处理好TODO标记.
  3. 【强制】开发人员对代码进行修改时必须将被修改文件 checkout 后进行修改。
  4. 【推荐】设计文档，程序编码都必须放到版本控制中去。
  5. 【强制】有重大修改，或影响其他人工作的修改，要发送邮件通知。
  6. 【推荐】版本服务器的数据要定期进行备份。
  7. 【推荐】修改完成的文档，编码要迅速提交到版本控制服务器。
    说明：修改要注明版本和修改时间，人员及简要的修改说明。
  8. 【推荐】 在本地测试通过的文档和程序才能提交到版本控制服务器，如果因特殊需要要求提交到版本服务器，但本机测试还没通过时，请注明。
  9. 【推荐】 本项目开发采用的是瀑布方式，因此当代码形成一个可测试的版本之后，要求测试人员在未完成当前版本的测试之前，不允许更新下一版的代码，从而造成不必要的测试版本错乱。

# Git 提交规范

# 描述

Git 提交规范说明.

# commit message 格式说明

Commit message 一般包括三部分：Header、Body 和 Footer。

type(scope):subject

  • type：用于说明 commit 的类别，规定为如下几种
  • feat：新增功能；
  • fix：修复 bug；
  • docs：修改文档；
  • refactor：代码重构，未新增任何功能和修复任何 bug；
  • build：改变构建流程，新增依赖库、工具等（例如 webpack 修改）；
  • style：仅仅修改了空格、缩进等，不改变代码逻辑；
  • perf：改善性能和体现的修改；
  • chore：非 src 和 test 的修改；
  • test：测试用例的修改；
  • ci：自动化流程配置修改；
  • revert：回滚到上一个版本；
  • scope：【可选】用于说明 commit 的影响范围
  • subject：commit 的简要说明，尽量简短

# Body

对本次 commit 的详细描述，可分多行

不兼容变动：需要描述相关信息 关闭指定 Issue：输入 Issue 信息

# 只需提交源码及构建文件，即

src     //源码
pom.xml //构建文件
.classpath //此文件只允许common-config项目提交

← 前端开发规范 →