数据仓库代码版本与提交管理指南

一、代码分支管理

在使用GitLab进行数据仓库项目的开发过程中，我们采用了一种基于gitflow的工作流程，但由于历史原因，当前实施的是非标准的gitflow模型。以下是现有的分支结构及其权限分配：

二、Git提交信息规范

为了保持代码提交的一致性和可读性，我们建议开发者使用IntelliJ IDEA中的git commit template插件来辅助提交。每个提交的信息应包含以下几个部分：

• 变更类型：包括feat（新特性）、fix（修复bug）、docs（文档更新）、style（代码风格调整）、refactor（代码重构）、perf（性能优化）、test（测试相关）、build（构建系统或外部依赖更改）、ci（持续集成配置文件或脚本更改）、chore（其他不影响源码或测试文件的更改）、revert（回滚先前的提交）等。
• 变更范围：指明提交影响的模块或组件。
• 简短描述：对本次提交的核心内容进行简要概述。
• 详细描述：如果需要，提供关于此次变更的更多细节。
• 重大变更：列出可能破坏现有功能的更改点。
• 关闭问题：提及此次提交解决了哪些已知问题。

三、代码提交流程

1. 稳定的生产代码存储于master分支，新的功能开发应在创建的特性分支上进行。

2. 特性开发完成后，先合并至开发分支（develop），在此阶段进行初步的功能整合与调试。若发现需要修正的问题，应在特性分支上完成修复并重新合并至develop分支。

3. 调试无误后，将特性分支合并至sit分支，准备进行系统集成测试。测试过程中发现的任何缺陷都应回到特性分支解决，并再次合并至sit分支。

4. 测试通过后，特性分支将被合并至uat分支，以供最终用户验收。如有必要调整，同样在特性分支执行，并重新部署uat环境验证。

5. 验收成功后，从最近的一个发布版本创建一个新的分支作为上线版本，同时保留旧版作为备份。特性分支将被合并至此新分支中，以便部署上线。

6. 生产环境的发布版本将保留最近三个版本的历史记录，新版本上线后，最老的版本将被移除。

7. 若生产环境中出现故障，应从最新的发布版本创建hotfix分支，修复完毕后遵循相同的测试流程，确保问题得到妥善处理后再合并至主发布分支上线。

8. 每次生产版本发布完成后，务必同步将特性分支合并回dev/sit和uat分支，以保证各环境间的代码一致性。

参考资料：

• IDEA集成Git教程
• Git Commit Message模板
• GitLab Projects Jetbrains IDE插件介绍
• Git官方文档
• 项目成员权限设置指导