You need to enable JavaScript to run this app.
文档中心
大数据研发治理套件

大数据研发治理套件

复制全文
下载 pdf
发布、部署与环境
基于 Git 的版本管理
复制全文
下载 pdf
基于 Git 的版本管理

本文介绍 DataLeap New IDE 如何利用 Git 实现代码与配置的版本管理,涵盖分支策略、Merge Request 流程、Code Review 规范和变更追溯。

Git 原生的存储模型

DataLeap New IDE 以 Git 作为唯一的代码与配置存储层。每个 Project 对应一个 Git 仓库,所有资源文件均存储在仓库中:

文件类型

存储格式

示例

Pipeline 配置

YAML

daily_etl.pipeline.yml

SQL 脚本

.sql + .sql.metadata.yml

extract.sql

Notebook

.notebook + .notebook.metadata.yml

analysis.notebook

Python 脚本

.py + .py.metadata.yml

transform.py

Shell 脚本

.sh + .sh.metadata.yml

cleanup.sh

优势:

  • 所有变更均有完整的 Git 提交记录。
  • 可使用任意 IDE 或编辑器打开和编辑。
  • 天然兼容企业现有的 Git 治理规范。
  • 支持 CI/CD 集成。

分支策略

推荐的分支模型

DataLeap New IDE 推荐使用 Feature Branch 工作流:

main (主干分支)
 ├── feature/add-order-etl       (功能开发分支)
 ├── feature/optimize-transform  (优化分支)
 └── fix/partition-path-error    (修复分支)

分支类型

命名规范

用途

主干分支

main / master

稳定版本,生产发布从此分支打包。

功能分支

feature/<描述>

新功能开发

修复分支

fix/<描述>

缺陷修复

紧急分支

hotfix/<描述>

生产环境紧急修复

分支操作

  • 创建分支:
    在 Web IDE 左下角的分支选择器中,点击"新建分支",输入分支名称,系统自动从当前分支创建新分支。
  • 切换分支:
    在分支选择器中点击目标分支名称即可切换。切换后工作空间中的文件自动更新为目标分支的内容。
  • 删除分支:
    功能分支合入主干后应及时删除,保持分支列表整洁。

Merge Request

创建 Merge Request

功能开发完成后,通过 Merge Request(MR)将变更合入主干:

  1. 在 Web IDE 中提交所有代码变更并推送至远端。
  2. 进入 MR 管理页面,点击"新建 Merge Request"。
  3. 选择源分支(Feature Branch)和目标分支(主干)。
  4. 填写 MR 信息:
    • 标题:简明概括变更内容。
    • 描述:详细说明变更背景、影响范围和测试结果。
    • Reviewer:指定一名或多名审查人。

MR 内容展示

MR 页面自动展示以下信息:

信息

说明

文件变更列表

本次 MR 涉及的所有文件及变更状态(新增/修改/删除)。

Diff 对比

逐行对比每个文件的变更内容。

Commit 记录

本次 MR 包含的所有 Git commit。

评论

Reviewer 可在具体代码行上添加评审意见。

Code Review

审查要点

Reviewer 应关注以下方面:

审查维度

检查内容

Pipeline 配置

metadata.name 是否合理、trigger 配置是否正确、dependsOn 依赖是否完整。

参数引用

参数是否已定义、引用语法是否正确、环境相关配置是否使用了项目参数。

脚本逻辑

SQL 逻辑是否正确、是否存在全表扫描等性能问题、分区过滤是否完整 。

重试与超时

关键 Activity 是否配置了合理的 retryPolicytimeoutSeconds

数据产出

dataOutputs 是否与实际写入的表/分区一致 。

安全合规

是否存在硬编码的密钥、敏感信息或不必要的权限配置。

审查流程

Reviewer 审查代码
  → 发现问题 → 添加评论,标记"需修改" → 开发者修改并重新提交
  → 审查通过 → 批准 MR → 合入主干

评论与讨论

  • Reviewer 可在 diff 视图的具体代码行添加评论。
  • 开发者可回复评论、解释设计决策或确认修改。
  • 所有评论记录完整保留,便于后续回顾。

变更追溯

查看文件历史

在 Web IDE 中右键文件,选择"查看历史",可查看该文件的完整 Git 提交记录:

  • 每次变更的 commit message、作者和时间。
  • 任意两个版本之间的 diff 对比。
  • 可回溯到任意历史版本查看当时的文件内容。

查看 Pipeline 变更记录

Pipeline 配置文件的 Git 历史完整记录了每一次变更:

  • 谁在什么时间修改了什么内容。
  • 每次修改通过哪个 MR 合入。
  • 关联的 Code Review 评论和审批记录。

Blame 视图

通过 Git Blame 查看文件中每一行代码的最后修改者和修改时间,快速定位问题代码的引入时间点。

冲突处理

当多名开发者修改了同一文件时,合入主干可能出现冲突。

冲突类型

冲突场景

说明

Pipeline YAML 冲突

多人修改了同一 Pipeline 的不同 Activity。

脚本代码冲突

多人修改了同一 SQL/Python 脚本。

元数据冲突

多人修改了同一脚本的 metadata 配置。

解决方式

  1. 在 MR 页面查看冲突文件和冲突内容。
  2. 手动编辑冲突文件,保留正确的版本。
  3. 提交解决冲突的 commit。
  4. 重新请求 Review。

说明

建议通过合理的文件组织和任务分工减少冲突,如不同开发者负责不同的 Pipeline 和脚本文件。

最佳实践

实践

说明

小粒度分支

每个分支聚焦一个功能或修复,缩短分支生命周期。

及时合入

Feature Branch 开发完成后尽快合入主干,减少冲突风险。

规范 commit message

使用统一格式,如 feat: / fix: / refactor: 前缀。

必须 Code Review

所有合入主干的变更必须经过至少一人审查。

保护主干分支

禁止直接向主干推送代码,必须通过 MR 合入。

清理已合入分支

MR 合入后及时删除 Feature Branch。

最近更新时间:2026.06.12 11:44:16
这个页面对您有帮助吗?
有用
有用
无用
无用