本文介绍 DataLeap New IDE 如何利用 Git 实现代码与配置的版本管理,涵盖分支策略、Merge Request 流程、Code Review 规范和变更追溯。
DataLeap New IDE 以 Git 作为唯一的代码与配置存储层。每个 Project 对应一个 Git 仓库,所有资源文件均存储在仓库中:
文件类型 | 存储格式 | 示例 |
|---|---|---|
Pipeline 配置 | YAML |
|
SQL 脚本 |
|
|
Notebook |
|
|
Python 脚本 |
|
|
Shell 脚本 |
|
|
优势:
DataLeap New IDE 推荐使用 Feature Branch 工作流:
main (主干分支) ├── feature/add-order-etl (功能开发分支) ├── feature/optimize-transform (优化分支) └── fix/partition-path-error (修复分支)
分支类型 | 命名规范 | 用途 |
|---|---|---|
主干分支 |
| 稳定版本,生产发布从此分支打包。 |
功能分支 |
| 新功能开发 |
修复分支 |
| 缺陷修复 |
紧急分支 |
| 生产环境紧急修复 |
功能开发完成后,通过 Merge Request(MR)将变更合入主干:
MR 页面自动展示以下信息:
信息 | 说明 |
|---|---|
文件变更列表 | 本次 MR 涉及的所有文件及变更状态(新增/修改/删除)。 |
Diff 对比 | 逐行对比每个文件的变更内容。 |
Commit 记录 | 本次 MR 包含的所有 Git commit。 |
评论 | Reviewer 可在具体代码行上添加评审意见。 |
Reviewer 应关注以下方面:
审查维度 | 检查内容 |
|---|---|
Pipeline 配置 |
|
参数引用 | 参数是否已定义、引用语法是否正确、环境相关配置是否使用了项目参数。 |
脚本逻辑 | SQL 逻辑是否正确、是否存在全表扫描等性能问题、分区过滤是否完整 。 |
重试与超时 | 关键 Activity 是否配置了合理的 |
数据产出 |
|
安全合规 | 是否存在硬编码的密钥、敏感信息或不必要的权限配置。 |
Reviewer 审查代码 → 发现问题 → 添加评论,标记"需修改" → 开发者修改并重新提交 → 审查通过 → 批准 MR → 合入主干
在 Web IDE 中右键文件,选择"查看历史",可查看该文件的完整 Git 提交记录:
Pipeline 配置文件的 Git 历史完整记录了每一次变更:
通过 Git Blame 查看文件中每一行代码的最后修改者和修改时间,快速定位问题代码的引入时间点。
当多名开发者修改了同一文件时,合入主干可能出现冲突。
冲突场景 | 说明 |
|---|---|
Pipeline YAML 冲突 | 多人修改了同一 Pipeline 的不同 Activity。 |
脚本代码冲突 | 多人修改了同一 SQL/Python 脚本。 |
元数据冲突 | 多人修改了同一脚本的 metadata 配置。 |
说明
建议通过合理的文件组织和任务分工减少冲突,如不同开发者负责不同的 Pipeline 和脚本文件。
实践 | 说明 |
|---|---|
小粒度分支 | 每个分支聚焦一个功能或修复,缩短分支生命周期。 |
及时合入 | Feature Branch 开发完成后尽快合入主干,减少冲突风险。 |
规范 commit message | 使用统一格式,如 |
必须 Code Review | 所有合入主干的变更必须经过至少一人审查。 |
保护主干分支 | 禁止直接向主干推送代码,必须通过 MR 合入。 |
清理已合入分支 | MR 合入后及时删除 Feature Branch。 |