数据分析团队如何在 Azure DevOps 中组织 monorepo？

2026-11-04数据小陈

结论：可以采用共享 monorepo，先明确资源边界

数据分析团队可以把 SQL、ETL、报表定义和相关代码放在一个 Git 仓库中。monorepo 不要求所有文件属于同一个大型应用，不同工单之间也不必存在代码依赖。

考虑到你们目前有内部限制，且倾向使用共享仓库，可以先采用这一方案。前提是仓库内的资源适合共享访问，并且能明确每项资源的负责人、验证方式和发布范围。现有材料没有提供其他团队的实施结果，无法保证规模扩大后仍然顺畅。

多人协作的压力主要来自共享文件和流程

Git 分支属于整个仓库，但合并冲突通常取决于双方具体修改的内容。两个人分别修改不同目录下的独立 SQL 文件，通常不会仅因为共用仓库而产生内容冲突。

以下情况更容易带来协作困难：

多个工单频繁修改同一个 SQL 文件、公共配置或共享 ETL 模块。
分支长期不合并，积累大量变更。
一次提交混入多个无关需求，增加审查和回退难度。
任意目录发生变更，都触发全部资源的验证和部署。
自动生成文件或 notebook 元数据反复变化，掩盖实际逻辑修改。

判断是否需要拆分仓库，应结合这些问题，而不能只看参与人数。

目录应围绕长期维护的资源组织

原始目录示例没有缩进，无法确定准确的父子关系。另外，Fabric 和 Oracle 更接近平台划分；如果团队希望按业务领域组织，需要进一步明确哪一种作为顶层规则。

如果日常维护主要按平台分工，可以参考下面的结构。这个层级是建议，原始示例并未明确这些关系：

Data-and-Analytics-Projects/
├── README.md
├── .gitignore
├── Fabric/
│   ├── etl/
│   │   └── monthly_arrears_query/
│   │       ├── monthly_arrears_query.sql
│   │       └── README.md
│   ├── notebooks/
│   ├── api/
│   └── sql/
└── Oracle/
    └── ccs/
        ├── severance_update/
        │   ├── severance_update.sql
        │   └── README.md
        └── test_dim_sa/
            ├── test_dim_sa.sql
            └── README.md

如果需求通常跨平台，但围绕同一个业务领域交付，也可以先按业务领域分目录，再区分平台。选择团队最容易定位资源的方式即可，同时避免同类资源在多个位置重复存放。

工单编号适合放在分支名、提交说明和 PR 中。长期维护的资源目录应保持稳定，避免每处理一个工单就复制一套脚本。

每项资源的 README.md 至少应写清用途、负责人、输入输出、依赖、运行方法和验证方法。会修改数据的脚本还应说明适用环境、执行顺序和恢复办法。

用短分支和小 PR 处理独立工单

可以为单个需求创建短期分支，让每个 PR 聚焦一项可独立审查的变更。例如：

git switch main
git pull --ff-only
git switch -c work/1234-monthly-arrears

# 修改并检查相关文件后，仅暂存本次需求涉及的内容
 git add Fabric/etl/monthly_arrears_query/
git commit -m "Update monthly arrears query"
git push -u origin work/1234-monthly-arrears

示例假设默认分支名为 main，本地工作区没有待处理的修改。分支名和路径应按实际情况替换。

提交后通过 PR 审查，重点检查逻辑、依赖变化和验证证据。不要把某个工单的分支长期用作该资源的维护分支，否则后续修改容易分散在不同分支中。

按资源范围验证和发布

共享仓库可以包含多个独立的验证和发布单元。例如，只修改一个 Oracle SQL 资源时，可以先验证该资源及其依赖，不必因此部署所有 Fabric 内容。

如果后续配置按路径触发的流水线，需要把共享模块和公共配置纳入依赖判断。只根据修改文件所在目录确定验证范围，可能漏掉受影响的下游资源。

SQL 通过语法检查不代表业务结果正确。还需要结合目标数据库、输入数据和预期结果进行验证；涉及数据写入时，先在合适的测试环境中确认影响范围。具体检查方式取决于你们使用的数据库和运行工具。

哪些情况值得拆成多个仓库？

出现以下情况时，应重新评估仓库边界：

不同团队需要严格隔离代码读取权限。Git 目录不能作为可靠的读取权限隔离边界。
各部分有独立的维护团队和发布流程，共享仓库持续增加协调成本。
大文件或生成文件使仓库历史不断膨胀，影响日常获取和维护代码。
公共配置经常引发跨团队冲突，而且难以通过调整目录和流程解决。

报表导出文件也需要区分用途：生成报表的代码、定义和少量脱敏样例适合版本管理；大量运行结果通常更适合独立的数据或制品存储。连接密码、访问令牌和敏感业务数据不应提交到仓库。

可以先选一组实际资源，走一遍分支、审查、验证和发布流程，再根据遇到的具体问题调整目录或拆分仓库。