Databricks Git 文件夹和 Git 集成具有在以下部分中指定的限制。 有关常规信息，请参阅 Databricks 限制。
跳转到：
若要了解 Git 文件夹中支持的 Databricks 资产类型，请参阅 Git 文件夹支持哪些资产类型？
文件和存储库限制
Azure Databricks 不会对存储库的大小强制施加限制。 但是：
- 工作分支限制为 1 GB。
- 大于 10 MB 的文件无法在 Azure Databricks UI 中查看。
- 单个工作区文件有单独的大小限制。 有关更多详细信息，请阅读限制。
Databricks 建议在存储库中：
- 工作区资产和文件的总数不超过 20,000。
对于任何 Git作，内存使用量限制为 2 GB，磁盘写入限制为 4 GB。 由于此限制是针对每个操作的，如果尝试克隆一个大小为 5 GB 的 Git 存储库，就会失败。 但如果在一个操作中克隆大小为 3 GB 的 Git 存储库，然后稍后向其添加 2 GB，则下一个拉取操作将成功。
如果存储库超出这些限制，可能会收到错误消息。 克隆存储库时，即使操作仍会在后台完成，你也可能收到超时错误。
若要使用超过大小限制的存储库，请尝试稀疏签出。
如果必须编写在群集关闭后不想保留的临时文件，将临时文件写入到 $TEMPDIR 可以避免超过分支大小限制，并且如果 CWD 位于工作区文件系统中，则产生的性能会优于写入当前工作目录 (CWD)。 有关详细信息，请参阅应在 Azure Databricks 上的什么位置编写临时文件？。
每个工作区的最大 Git 文件夹数
每个工作区最多可以有 2,000 个 Git 文件夹。 如果需要更多，请联系 Databricks 支持。
恢复从工作区中的 Git 文件夹删除的文件
Git 文件夹中的工作区操作在文件可恢复性上有所不同。 某些操作允许通过 回收站 文件夹恢复，而另一些操作则不允许。 以前提交并推送到远程分支的文件可以使用远程 Git 存储库的 Git 提交历史记录进行还原。 下表概述了每个操作的行为和可恢复性：
| 操作 | 文件是否可恢复？ |
|---|---|
| 使用工作区浏览器删除文件 | 是，来自回收站文件夹 |
| 使用 Git 文件夹对话框放弃新文件 | 是，从回收站文件夹 |
| 使用 Git 文件夹对话框放弃已修改的文件 | 否，文件已消失 |
reset（硬）用于未提交的文件修改 |
否，文件修改已消失 |
reset（强制）用于新创建且未提交的文件 |
否，文件修改已消失 |
| 使用 Git 文件夹对话框切换分支 | 是，来自远程 Git 存储库 |
| Git 文件夹对话框中的其他 Git 操作，例如提交或推送 | 是，来自远程 Git 存储库 |
从 Repos API 更新 /repos/id 的 PATCH 操作 |
是，来自远程 Git 存储库 |
单存储库支持
Databricks 建议不要创建 由 monorepos 支持的 Git 文件夹。 monorepo 是一个大型的单组织 Git 存储库，其中包含多个项目中的数千个文件。
常见问题解答：Git 文件夹配置
Azure Databricks 存储库内容存储在何处？
存储库的内容被暂时克隆到控制平面上的磁盘中。 Azure Databricks 笔记本文件存储在控制平面数据库中，与主工作区中的笔记本一样。 非笔记本文件最多在磁盘上存储 30 天。
Git 文件夹是否支持本地或自承载 Git 服务器？
如果服务器可通过 Internet 访问，Databricks Git 文件夹支持与 GitHub Enterprise、Bitbucket Server、Azure DevOps Server 和 GitLab 自托管的集成。 有关将 Git 文件夹与本地 Git 服务器集成的详细信息，请阅读 Git 文件夹的 Git 代理服务器。
若要与 Bitbucket 服务器、GitHub Enterprise Server 或无法访问 Internet 的 GitLab 自托管订阅实例集成，请联系 Azure Databricks 帐户团队。
Git 文件夹支持哪些 Databricks 资源类型？
有关支持的资产类型的详细信息，请参阅 Git 文件夹支持哪些资产类型？
Git 文件夹是否支持 .gitignore 文件？
是的。 如果将某个文件添加到存储库，并且不希望 Git 跟踪该文件，请创建一个 .gitignore 文件或使用从远程存储库克隆的文件，并添加文件名（包括文件扩展名）。
.gitignore 仅适用于 Git 尚未跟踪的文件。 如果将 Git 已跟踪的文件添加到 .gitignore 文件中，Git 仍会跟踪该文件。
Git 文件夹是否支持 Git 子模块？
否。 可以克隆包含 Git 子模块的存储库，但不会克隆子模块。
Azure 数据工厂 (ADF) 是否支持 Git 文件夹？
是的。
源管理
为什么在拉取或签出其他分支时笔记本仪表板会消失？
这是一个限制，因为 Azure Databricks 笔记本源文件不存储笔记本仪表板信息。
若要在 Git 存储库中保留仪表板，请将笔记本格式更改为 .ipynb （Jupyter 笔记本格式）。 默认情况下，.ipynb 支持仪表板和可视化定义。 要保留图形数据（数据点），您必须提交包含输出的笔记本。
若要了解如何提交 .ipynb 笔记本输出，请参阅 管理 IPYNB 笔记本输出提交。
Git 文件夹是否支持分支合并？
是的。 也可以创建拉取请求并通过 Git 提供程序进行合并。
能否从 Azure Databricks 存储库中删除分支？
否。 若要删除分支，必须在 Git 提供程序中工作。
如果某个库安装在群集上，并且存储库中的文件夹中包含具有相同名称的库，则会导入哪个库？
将导入存储库中的库。 有关 Python 中的库优先级的详细信息，请参阅 Python 库优先级。
是否可以在不依赖外部业务流程工具的情况下，在运行作业之前从 Git 中拉取最新版本的存储库？
否。 通常，可以将此操作集成为 Git 服务器上的预提交挂钩，可在每次推送到分支（主/生产）时都更新生产存储库。
是否可以导出存储库？
可以导出笔记本、文件夹或整个存储库。 无法导出非笔记本文件。 如果导出整个存储库，将不包括非笔记本文件。 若要导出，请在 workspace export 中使用命令，或者使用 工作区 API。
安全性、身份验证和令牌
Microsoft Entra ID 的条件访问策略 (CAP) 出现问题
尝试克隆存储库时，可能会在以下情况下收到“拒绝访问”错误消息：
- Azure Databricks 配置为将 Azure DevOps 与 Microsoft Entra ID 身份验证配合使用。
- 你已在 Azure DevOps 中启用条件访问策略且启用了 Microsoft Entra ID 条件访问策略。
若要解决此问题，请为 Azure Databricks IP 地址或用户的条件访问策略 (CAP) 添加排除项。
有关详细信息，请参阅条件访问策略。
包含 Microsoft Entra ID 令牌的允许列表
如果使用 Microsoft Entra ID 通过 Azure DevOps 进行身份验证，则默认允许列表将 Git URL 限制为：
dev.azure.comvisualstudio.com
有关详细信息，请参阅允许列表限制使用远程存储库。
Azure Databricks Git 文件夹的内容是否加密？
Azure Databricks Git 文件夹的内容将由 Azure Databricks 使用默认密钥进行加密。 除非加密 Git 凭据，否则不支持使用客户管理的密钥进行加密。
Github 令牌在 Azure Databricks 中的存储方式和位置是什么？ 谁可以访问 Azure Databricks？
- 身份验证令牌存储在 Azure Databricks 控制平面中，Azure Databricks 员工只能通过经审核的临时凭据获取访问权限。
- Azure Databricks 记录这些令牌的创建和删除，但不记录其使用情况。 Azure Databricks 会通过日志记录跟踪 Git 操作，这些日志可用于审核 Azure Databricks 应用程序的令牌使用情况。
- GitHub 企业审核令牌使用情况。 其他 Git 服务也可能进行 Git 服务器审核。
Git 文件夹是否支持对提交进行 GPG 签名？
否。
Git 目录是否支持使用 SSH 进行 Git 操作？
不，只有支持 HTTPS 协议。
将 Azure Databricks 连接到不同租户中的 Azure DevOps 存储库时出错
尝试在单独的租户中连接到 DevOps 时，可能会收到消息 Unable to parse credentials from Azure Active Directory account。 如果 Azure DevOps 项目与 Azure Databricks 位于不同的 Microsoft Entra ID 租户中，则必须使用来自 Azure DevOps 的访问令牌。 请参阅使用 DevOps 令牌连接 Azure DevOps。
CI/CD 和 MLOps
传入更改清除笔记本状态
更改笔记本源代码的 Git 操作会导致笔记本状态丢失，包括单元格输出、注释、版本历史记录和小组件。 例如，git pull 可以更改笔记本的源代码。 在这种情况下，Databricks Git 文件夹必须覆盖现有笔记本才能导入更改。 git commit 和 push 或创建新分支不会影响笔记本源代码，因此在这些操作中笔记本状态会被保留。
重要
MLflow 实验在 DBR 14.x 或更低版本的 Git 文件夹中不起作用。
是否可以在 Git 文件夹中创建 MLflow 试验？
有两种类型的 MLflow 试验：工作区和笔记本。 有关两种类型的 MLflow 试验的详细信息，请参阅使用 MLflow 试验组织训练运行。
工作区试验：无法在 Git 文件夹中创建工作区 MLflow 试验。 相反，将 MLflow 运行记录到常规工作区文件夹中创建的 MLflow 实验中。 如果多个用户使用单独的 Git 文件夹协作处理同一代码，请将 MLflow 运行记录到在共享工作区文件夹中创建的 MLflow 实验中。
笔记本试验：可以在 Databricks Git 文件夹中创建笔记本试验。 如果将笔记本文件作为
.ipynb文件签入源代码管理，那么可以将 MLflow 运行记录到自动创建并关联的 MLflow 实验。 但是，试验和关联的运行不会签入源代码管理。 若要了解详细信息，请参阅 创建笔记本试验。
防止 MLflow 试验中的数据丢失
使用源代码位于远程存储库中的 Databricks 作业创建的笔记本 MLflow 试验存储在临时存储位置。 这些试验最初会在工作流执行后保留，但之后在计划内的临时存储内文件移除期间，它们将面临被删除的风险。 Databricks 建议在作业和远程 Git 源中使用工作区 MLflow 试验。
警告
切换到不包含笔记本的分支时，可能会丢失关联的 MLflow 试验数据。 如果在 30 天内未访问之前的分支，则此损失将永久化。
若要在 30 天到期前恢复缺少的试验数据，请将笔记本名称更改为原始名称，打开笔记本，然后单击右侧窗格中的 
，这会触发对函数的 mlflow.get_experiment_by_name() 调用。 函数返回时，可以看到恢复的试验和运行。 30 天后，任何无主的 MLflow 实验将被清除，以符合 GDPR 合规性策略。
为防止这种情况，Databricks 建议不要重命名存储库中的笔记本。 如果确实重命名笔记本，请在重命名笔记本后立即单击右侧窗格中的“试验”图标。
在 Git 操作进行期间，如果笔记本作业在工作区中运行，会发生什么情况？
在任何 Git 操作正在进行时，存储库中的某些笔记本可能已经更新，而其他的则可能没有更新。 这可能会导致不可预知的行为。
例如，假设 notebook A 使用 %run 命令调用 notebook Z。 如果在进行 Git 操作期间运行的作业启动了最新版本的 notebook A，但 notebook Z 尚未更新，则 notebook A 中的 %run 命令可能启动较旧版本的 notebook Z。 在 Git 操作期间，笔记本状态不可预知，作业可能会失败，或者从不同的提交运行 notebook A 和 notebook Z。
为了避免这种情况，请将作业任务配置为使用 Git 提供程序作为源，而不是工作区路径。 若要了解详细信息，请参阅 将 Git 与作业配合使用。
资源
有关 Databricks 工作区文件的详细信息，请参阅什么是工作区文件？。