Git と Databricks Git フォルダーの統合に関する制限と FAQ

2025-04-09

Databricks Git フォルダーと Git の統合には、次の各セクションに記載されている制限があります。一般的な情報については、Databricks の制限をご覧ください。

ジャンプ先:

ファイルとリポジトリの制限
FAQ: Git フォルダーの構成

Git フォルダーでサポートされている Databricks アセットの種類については、「Git フォルダーでサポートされるアセットの種類」を参照してください。

ファイルとリポジトリの制限

Azure Databricks では、リポジトリのサイズに制限は適用されません。ただし

作業ブランチは 1 GB (ギガバイト) に制限されています。
10 MB を超えるファイルは、Azure Databricks UI では表示できません。
個々のワークスペースファイルには、個別のサイズ制限が適用されます。詳細については、「制限」を参照してください。
ブランチのローカルバージョンは、リモートブランチが削除されてから最大で 30 日間、関連付けられている Git フォルダーに存在できます。 Git フォルダー内のローカルブランチを完全に削除するには、リポジトリを削除します。

Databricks では、リポジトリについて次のことが推奨されています。

ワークスペースの資産とファイルの合計数は 20,000 を超えません。

Git 操作の場合、メモリ使用量は 2 GB に制限され、ディスク書き込みは 4 GB に制限されます。この制限は操作ごとに行われるため、サイズが 5 GB の Git リポジトリを複製しようとすると、エラーが発生します。ただし、サイズが 3 GB の Git リポジトリを 1 回の操作でクローンし、後で 2 GB を追加する場合、次のプル操作は成功します。

リポジトリがこれらの制限を超えている場合は、エラーメッセージが表示されることがあります。操作がバックグラウンドで完了する場合でも、リポジトリの複製時にタイムアウトエラーが発生する場合もあります。

サイズ制限を超えるリポジトリを操作するには、スパースチェックアウトを試してください。

クラスターのシャットダウン後に保持しない一時ファイルを書き込む必要がある場合は、 $TEMPDIR に一時ファイルを書き込むと、ブランチサイズの制限を超えないようにし、ワークスペースファイルシステムの作業ディレクトリ (CWD) に書き込むよりもパフォーマンスが向上します。詳細については、「 Azure Databricks で一時ファイルを書き込む必要がある場所」を参照してください。

ワークスペース内の Git フォルダーから削除されたファイルの回復

Git フォルダーのワークスペースアクションは、ファイルの回復可能性によって異なります。一部のアクションでは ごみ箱 フォルダーを通じて回復が可能ですが、そうでないアクションもあります。以前にコミットされ、リモートブランチにプッシュされたファイルは、リモート Git リポジトリの Git コミット履歴を使用して復元できます。次の表は、各アクションの動作と回復可能性の概要を示しています。

アクション	ファイルは回復可能ですか?
ワークスペースブラウザーでファイルを削除する	はい。 Trash フォルダーから
[Git フォルダー] ダイアログで新しいファイルを破棄する	はい。 Trash フォルダーから
[Git フォルダー] ダイアログで変更したファイルを破棄する	いいえ、ファイルは削除されています
`reset` (ハード) コミットされていないファイル変更の場合	いいえ、ファイルの変更は行われません
`reset` (ハード) コミットされていない新しく作成されたファイルの場合	いいえ、ファイルの変更は行われません
Git フォルダーダイアログでブランチを切り替える	はい(リモート Git リポジトリから)
Git フォルダーダイアログからのその他の Git 操作 (コミットやプッシュなど)	はい(リモート Git リポジトリから)
`PATCH` Repos API から `/repos/id` を更新する操作	はい(リモート Git リポジトリから)

Monorepo のサポート

Databricks では、 monorepos によってサポートされる Git フォルダーを作成しないことをお勧めします。 monorepo は、多数のプロジェクトにわたって何千ものファイルを含む大規模な単一組織 Git リポジトリです。

よく寄せられる質問: Git フォルダーの構成

Azure Databricks リポジトリのコンテンツはどこに格納されますか?

リポジトリの内容は、コントロールプレーンのディスクに一時的にクローンされます。 Azure Databricks のノートブックファイルは、メインワークスペースのノートブックと同じように、コントロールプレーンのデータベースに格納されます。ノートブック以外のファイルは、最大 30 日間ディスクに格納されます。

Git フォルダーではオンプレミスまたはセルフホステッドの Git サーバーはサポートされていますか?

サーバーがインターネットでアクセス可能な場合、Databricks Git フォルダーは、GitHub Enterprise、Bitbucket サーバー、Azure DevOps Server、GitLab 自己管理型統合をサポートしています。 Git フォルダーとオンプレミス Git サーバーの統合の詳細については、Git フォルダー用の Git Proxy Server を参照してください。

Bitbucket Server、GitHub Enterprise Server、またはインターネットにアクセスできない GitLab 自己管理サブスクリプションインスタンスと統合するには、Azure Databricks アカウントチームにお問い合わせください。

Git フォルダーでサポートされている Databricks アセットの種類は何ですか?

サポートされている成果物の種類の詳細については、「 Git フォルダーでサポートされるアセットの種類」を参照してください。

Git フォルダーは `.gitignore` ファイルをサポートしていますか?

はい。リポジトリに追加したファイルが、Git によって追跡されないようにしたい場合は、.gitignore ファイルを作成するか、リモートリポジトリからクローンしたものを使用して、拡張子を含むファイル名を追加します。

.gitignore は、Git によってまだ追跡されていないファイルに対してのみ機能します。 Git によって既に追跡されているファイルを .gitignore ファイルに追加した場合でも、そのファイルは Git によって追跡されます。

Git フォルダーでは Git のサブモジュールはサポートされていますか?

いいえ。 Git サブモジュールを含むリポジトリをクローンすることはできますが、サブモジュールはクローンされません。

Git フォルダーは Azure Data Factory (ADF) でサポートされていますか?

はい。

ソース管理

別のブランチをプルまたはチェックアウトするとノートブックダッシュボードが消えるのはなぜですか?

Azure Databricks ソース形式のノートブックにはノートブックダッシュボード情報が格納されないため、これは制限事項です。

Git リポジトリのダッシュボードを保持するには、ノートブックの形式を .ipynb (Jupyter Notebook 形式) に変更します。既定では、.ipynb はダッシュボードと視覚化の定義がサポートされています。視覚化データを保存するためには、出力を含むノートブックを保存する必要があります。

ノートブック出力 .ipynb コミットする方法については、「 IPYNB ノートブックの出力コミットの管理」を参照してください。

Git フォルダーではブランチのマージがサポートされていますか?

はい。 pull request を作成し、Git プロバイダーを通じてマージすることもできます。

Azure Databricks リポジトリからブランチを削除できますか?

いいえ。ブランチを削除するには、Git プロバイダーで作業する必要があります。

Python の依存関係が Git フォルダーに含まれている場合の優先順位は何ですか?

Git フォルダーに格納されている Python ライブラリは、他の場所に格納されているライブラリよりも優先されます。たとえば、ライブラリが Databricks コンピューティングにインストールされていて、同じ名前のライブラリが Git フォルダーに含まれている場合、Git フォルダー内のライブラリがインポートされます。 Python でのライブラリの優先順位の詳細については、「Python ライブラリの優先順位」を参照してください。

セキュリティ、認証、およびトークン

Microsoft Entra ID の条件付きアクセスポリシー (CAP) に関する問題

リポジトリを複製しようとすると、次の場合に "アクセス拒否" エラーメッセージが表示されることがあります。

Azure Databricks は、Microsoft Entra ID 認証で Azure DevOps を使用するように構成されています。
Azure DevOps の条件付きアクセスポリシーと Microsoft Entra ID 条件付きアクセスポリシーを有効にしました。

これを解決するには、Azure Databricks の IP アドレスまたはユーザーの条件付きアクセスポリシー (CAP) に除外を追加します。

詳しくは、条件付きアクセスポリシーに関するページをご覧ください。

Microsoft Entra ID トークンを含む許可リスト

Azure DevOps での認証に Microsoft Entra ID を使用する場合、既定の許可リストでは Git URL が以下に制限されます。

dev.azure.com
visualstudio.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 commitpushまたは新しいブランチの作成はノートブックのソースコードに影響しないため、これらの操作ではノートブックの状態が維持されます。

重要

MLflow 実験は、DBR 14.x 以前のバージョンの Git フォルダーでは機能しません。

Git フォルダーに MLflow 実験を作成できますか?

MLflow 実験には、ワークスペースとノートブックの 2 種類があります。 2 種類の MLflow 実験の詳細については、「MLflow 実験を使用してトレーニング実行を整理する」を参照してください。

ワークスペースの実験: Git フォルダーにワークスペース MLflow 実験を作成することはできません。代わりに、ログ MLflow は、通常のワークスペースフォルダーに作成された MLflow 実験に対して実行されます。複数のユーザーが別々の Git フォルダーを使用して同じコードで共同作業を行う場合、ログ MLflow は共有ワークスペースフォルダーに作成された MLflow 実験に対して実行されます。
ノートブックの実験: Databricks Git フォルダーにノートブック実験を作成できます。ノートブックを .ipynb ファイルとしてソース管理にチェックインすると、自動的に作成され関連付けられた MLflow 実験に MLflow 実行を記録できます。ただし、実験および関連する実行は、ソース管理にチェックインされません。詳細については、ノートブックの実験の作成に関するページを参照してください。

MLflow 実験でデータ損失を防止する

リモートリポジトリ内のソースコードで Lakeflow ジョブを使用して作成されたノートブック MLflow 実験は、一時ストレージの場所に格納されます。これらの実験はワークフローの実行後も最初は保持されますが、後で一時保存場所内のファイルのスケジュールされた削除中に削除される危険があります。 Databricks では、ワークスペース MLflow 実験を、ジョブおよびリモート Git ソースと共に使用することをお勧めします。

警告

ノートブックを含まないブランチに切り替えると、関連する MLflow 実験データが失われるリスクがあります。前のブランチが 30 日以内にアクセスされない場合、この損失は永続的になります。

30 日間の有効期限が切れる前に不足している実験データを回復するには、ノートブック名を元の名前に変更し、ノートブックを開き、右側のウィンドウの [ 実験] アイコンをクリックして、 mlflow.get_experiment_by_name() 関数の呼び出しをトリガーします。関数が戻ると、回復された実験と実行を確認できます。 30 日後、孤児となった MLflow 実験は、GDPR コンプライアンスポリシーを満たすために消去されます。

このような状況を防ぐために、Databricks ではリポジトリ内のノートブックの名前を変更しないことをお勧めします。ノートブックの名前を変更する場合は、ノートブックの名前を変更した直後に右側のウィンドウの [実験] アイコンをクリックします。

Git 操作の進行中、ワークスペースでノートブックジョブが実行されている場合はどうなりますか?

Git 操作が進行中の任意の時点で、リポジトリ内の一部のノートブックが更新されている場合もあれば、更新されていないノートブックもあります。これにより、予期しない動作が発生する可能性があります。

たとえば、notebook A が notebook Z コマンドを使用して %run を呼び出すとします。 Git 操作中に実行されているジョブが最新バージョンのnotebook Aを開始したが、notebook Zがまだ更新されていない場合は、%runの notebook A コマンドによって古いバージョンのnotebook Zが開始される可能性があります。 Git 操作中、ノートブックの状態は予測できず、ジョブが失敗したり、 notebook A 実行されたり、異なるコミットから notebook Z されたりする可能性があります。

このような状況を回避するには、ワークスペースパスではなくソースとして Git プロバイダーを使用するようにジョブタスクを構成します。詳細については、「ジョブで Git を使用する」を参照してください。

リソース

Databricks ワークスペースの詳細については、「ワークスペースファイルとは」を参照してください。