Git フォルダの作成と管理
このページでは、Databricks Git フォルダーを作成し、複製、分岐、コミット、プッシュなどの一般的な Git 操作を実行する方法について説明します。
このガイドでは、次の Git 操作について説明します。
リポジトリをクローンする
リモート リポジトリのクローンを作成すると、 Databricksワークスペースにリポジトリのコンテンツを含むGitフォルダーを作成し、変更を追跡します。 Databricks UI または Web ポータルを使用してGitフォルダーを作成できます。
- Git フォルダーを作成する親フォルダーに対する
CAN MANAGE権限が必要です。 - ワークスペースには Git 資格情報が設定されている必要があります。「Git プロバイダーを Databricks に接続する」を参照してください。
UIからクローン
-
サイドバーで 「ワークスペース」 を選択し、Git リポジトリのクローンを作成するフォルダーを参照します。
-
[作成] > [Git フォルダー] をクリックします。
-
「Git フォルダーの作成 」ダイアログで、以下の情報を入力します。
フィールド | 説明 |
|---|---|
GitリポジトリのURL | クローンを作成する Git リポジトリの URL (形式は |
Gitプロバイダー | クローンを作成するリポジトリの Git プロバイダー。 |
Gitフォルダ名 | クローンされたリポジトリの内容が含まれるワークスペース内のフォルダーの名前。 |
スパースチェックアウトモード | コーンパターンを使用してリポジトリのディレクトリのサブセットのみをクローンするスパースチェックアウトを使用するかどうか。これは、リポジトリのサイズ制限を超えた場合に役立ちます。 |
- Git フォルダを作成 をクリックします。リモート リポジトリのコンテンツはワークスペースにクローンされ、サポートされている Git 操作を開始できます。ワークスペースが条件を満たしている場合、GitフォルダーはGit CLIアクセスを有効にして自動的に作成されます。GitフォルダーはいつGit CLIアクセスを取得しますか？を参照してください。
Webターミナルからクローンする
Web ターミナルから直接CLIアクセスしてGitフォルダーを作成することもできます。
-
Webポータルにアクセスします。 Databricks Web ポータルの実行シェル コマンドを参照してください。
-
/Workspaceの親ディレクトリに移動します:Bashcd /Workspace/Users/<your-email>/<project> -
リポジトリをクローンします:
Bashgit clone <remote-url>git cloneコマンドは、ワークスペースで構成された Git 資格情報を使用します。「Git プロバイダーを Databricks に接続する」を参照してください。 -
ブラウザを更新すると、ワークスペース ファイル ブラウザに新しいフォルダが表示されます。
Git CLI コマンドを使用する
プレビュー
この機能はパブリック プレビューです。ワークスペース管理者は、 Git フォルダの Git CLI サポート へのアクセスを プレビュー ページから制御できます。「Databricksのプレビューを管理する」を参照してください。
Git CLI アクセス権を持つ Git フォルダを使用すると、ノートブック、Webターミナル、または Genie Code から Serverless コンピュートで標準の Git コマンドを実行できます。以下が可能です：
git stash、git push --force、git rebase -iを含む任意の Git コマンドを実行します。- コミット前のフックにリンティングとコードスキャンを統合します。
- 標準の Git フォルダーの 2 GB のメモリと 4 GB のディスク制限を超えるリポジトリを操作します。
- Git サブモジュールと Large File Storage (LFS) を使用します。
- リモート リポジトリにプッシュする前に、複数のコミットをローカルでステージングします。
Git CLIコンピュートの要件
必要なコンピュートは、 CLI対応のGitフォルダーの使用方法によって異なります。
オペレーション | コンピュート要件 |
|---|---|
UI から CLI アクセス可能な Git フォルダを作成する | |
Git フォルダ UI から Git 操作を実行する (プル、プッシュ、コミット) | |
ノートブック、Webターミナル、またはGenie CodeからGit CLIコマンドを実行 | Serverless コンピュート（環境バージョン 5 以降）またはクラシック コンピュート（Databricks Runtime 17.0 以降） |
サーバレス コンピュートを有効にするには、 「サーバレス コンピュートに接続する」を参照してください。
Git プロバイダーでプライベート ネットワーク接続が必要な場合は、 「ネットワーク接続の構成」を参照してください。
IDEまたはSSHトンネルを介してDatabricksコンピュートに接続されているターミナルから、Git CLIコマンドを実行することもできます。これは、ターミナルでのGit CLIコマンドのコンピュート要件を満たしています。
GitフォルダーはいつGit CLIアクセスを取得しますか？
UIからGitフォルダーを作成すると、ワークスペースが条件を満たしている場合、DatabricksはGit CLIアクセスを自動的に有効にします。お使いのワークスペースが対象でない場合、Databricks は代わりに標準の Git フォルダを作成し、引き続き Git フォルダの UI から Git 操作を実行できます。
UIから作成するGitフォルダーは、次のすべての条件が満たされている場合にGit CLIアクセスが有効になります。
- Git CLI プレビューは、お使いのワークスペースで有効になっています。ワークスペース管理者は、 プレビュー ページからこれを制御します。Databricks プレビューの管理を参照してください。
- Serverlessコンピュートはワークスペースでご利用いただけます。Serverless コンピュートに接続するを参照してください。
- Databricks は Serverless コンピュートから Git プロバイダーにアクセスできます。Databricksは、リポジトリをクローンする前に接続性を検証します。お使いの Git プロバイダーがプライベート ネットワーク接続を必要とする場合、ネットワーク接続を構成するを参照してください。
- パブリックプレビュー期間中は、リポジトリは 10,000 ファイルに制限されます。この制限を超えるリポジトリは、代わりに標準の Git フォルダとしてクローンされます。
Webターミナルからクローンした Git フォルダは、常に Git CLI にアクセスできます。
Git CLI アクセスで Git フォルダを作成する
CLI アクセスで Git フォルダーを作成するには:
- UIを使用する場合、ワークスペースが条件を満たしていると、DatabricksはGit CLIアクセスが有効なGitフォルダーを自動的に作成します。GitフォルダーはいつGit CLIアクセスを取得しますか？を参照してください。ワークスペースが条件を満たしていない場合、Databricksは代わりに標準のGitフォルダーを作成します。
- Web ポータルを使用している場合、クローンを作成したリポジトリには自動的にGit CLIアクセスが許可されます。
CLIアクセスでGitフォルダーを作成した後、Web ターミナルから標準のGitコマンドを実行します。 Web ターミナルを開くには、 「Web ターミナルを起動する」を参照してください。
cd /Workspace/Users/<your-email>/<project>/my-repo
# Interactive rebase
git rebase -i main
# Stash uncommitted changes
git stash
# Work with submodules
git submodule update --init --recursive
Git CLI の制限
CLI アクセスが可能な Git フォルダーには次の制限があります。
- Git URL 許可リストは、Databricks UI から実行する Git 操作に適用されますが、Git CLI で直接実行する Git コマンドには適用されません。
- Git CLI アクセス権を持つ Git フォルダは、List Repos APIでは返されません。
Git CLI 操作のトラブルシューティング
- ワークスペース UI でGit操作が無効になっています : ワークスペースでサーバレス コンピュートが有効になっていません。 Web ターミナルからは引き続きGitコマンドを実行できます。 サーバレス コンピュートを有効にするには、 「サーバレス コンピュートに接続する」を参照してください。
- ターミナルが資格情報の選択を促します ：Git CLI 操作は、保存されたワークスペースのGit 資格情報を自動的に使用します。Databricksは、リモートURLからGitプロバイダーを推測し、そのプロバイダーのdefault credentialを使用します。Databricksが使用する単一の認証情報を特定できない場合、いずれかを選択するよう求められます。プロンプトを回避するには、
DB_GIT_CREDENTIAL_NAME環境変数を使用する資格情報の名前に設定します。Databricksは、リポジトリに使用した認証情報を記憶し、再利用します。 - Git 操作が権限エラーで失敗しました : 親フォルダーに対する
CAN MANAGE権限があること、およびワークスペースの Git 資格情報が有効であることを確認してください。「Git プロバイダーを Databricks に接続する」を参照してください。
Git ダイアログにアクセスする
ノートブックまたは Databricks Git フォルダー ブラウザーから Git ダイアログにアクセスします。
-
ノートブックから、現在の Git ブランチを識別するノートブック名の横にあるボタンをクリックします。
-
Databricks Git フォルダー ブラウザーで、リポジトリ名の横にある Git をクリックします。
Git 操作を実行できる全画面ダイアログが表示されます。
- 現在の作業ブランチ。ここで他のブランチを選択できます。他のユーザーがこの Git フォルダーにアクセスできる場合、同じワークスペースを共有しているときは、ブランチを変更すると、そのユーザーのブランチも変更されます。この問題を回避するには、推奨されるベスト プラクティスを参照してください。
- 新しいブランチを作成します。
- 現在のブランチにチェックインされたファイル アセットとサブフォルダー。
- 現在のブランチ履歴を表示します。
- リモート Git リポジトリからコンテンツをプルします。
- 変更に対するコミット メッセージとオプションの詳細な説明を追加します。
- 作業を作業ブランチにコミットし、更新されたブランチをリモート Git リポジトリにプッシュします。
クリック
ケバブ メニューを使用して、ハードリセット、マージ、リベースなどの追加の Git ブランチ操作を選択します。
新しいブランチを作る
新しいブランチを作成するには:
- Git ダイアログを開きます。
- 「ブランチの作成」を クリックします。
- 新しいブランチの名前を入力し、ベース ブランチを選択します。
- 作成 をクリックします。
別のブランチに切り替える
別のブランチをチェックアウトするには、Git ダイアログのブランチ ドロップダウンを使用します。
現在のブランチのコミットされていない変更は、新しいブランチのコードと競合しない場合は、新しいブランチに引き継がれ、コミットされていない変更として表示されます。コミットされていない変更を引き継ぐつもりがない場合は、ブランチ切り替えの前後の変更を破棄します。
ブランチのローカル バージョンは、リモート ブランチを削除した後も、関連付けられている Git フォルダー内に最大 30 日間残ります。Git フォルダー内のローカル ブランチを完全に削除するには、リポジトリを削除します。
ブランチを切り替えると、新しいブランチにワークスペース アセットが含まれていない場合、ワークスペース アセットが削除される可能性があります。現在のブランチに戻すと、削除されたアセットが新しい ID と URL で再作成されます。この変更は元に戻せません。
Git フォルダーからアセットを共有またはブックマークした場合は、切り替える前に新しいブランチにアセットが存在することを確認してください。
変更をコミットしてプッシュする
新しいノートブックまたはファイルを追加したり、既存のノートブックまたはファイルに変更を加えたりすると、Git フォルダー UI で変更が強調表示されます。
変更に必要なコミット メッセージを追加し、 [コミット & プッシュ] をクリックして変更をリモートGitリポジトリにプッシュします。
デフォルト ブランチにコミットする権限がない場合は、新しいブランチを作成し、Git プロバイダーのインターフェースを使用してプル リクエストを作成し、それをデフォルト ブランチにマージします。
ノートブックがソース ファイル形式 ( .py 、 .scala 、 .sql 、 .r ) で保存されている場合、ノートブックの出力はコミットに含まれません。 ipynb形式を使用したノートブックのコミット出力については、 ipynbノートブック出力のアーティファクトコミットの制御」を参照してください。
役割としてのGitフォルダ作成者
RBACを使用すると、ロールを引き受けてそのロールにスコープされたデータにアクセスできます。そのデータを読み取るコードを作成するには、ロールを引き受けてデータアクセスを有効にし、変更をcommitします。自身のユーザーIDとして、またはロールとしてcommitできます。この選択によって、Gitプロバイダーがcommitをどのように帰属させるかが決まり、ワークフローに必要なセットアップの量とトレードオフされます。どちらもロールのGit資格情報に依存します。
アプローチ | commitの帰属先 | トレードオフ |
|---|---|---|
個別に | 詳細なセットアップ: Gitフォルダーを共有し、両方のIDからアクセスできるようにし、ユーザーIDに戻してcommitします。読み取り専用のロール資格情報で動作します。 | |
ロールです。 | よりシンプルに: あなたはロールとして機能し続け、フォルダを共有しません。コミットにはロールのGit識別情報が付与され、ロールのGit資格情報には書き込みアクセス権が必要であり、ロールを引き受けるすべてのユーザーと共有されます。 |
ユーザー ID で commit を行います
このアプローチでは、個人のGit資格情報でcommitするため、Gitプロバイダーがあなたにcommitを割り当てます。ロールがアクセスできるデータに対してのみオーサリングするためにロールを引き受け、その後ユーザーIDに戻ってcommitします。ロールとして作業しながらオーサリングし、ユーザーIDとしてcommitするため、Gitフォルダーは両方のIDからアクセス可能である必要があります。設定方法は2通りあり、フォルダの所有者と共有の方向によって異なります。
オプション1：ホームフォルダーにクローンしてロールと共有する
- ユーザーIDとして（ロールを引き受けずに）、リポジトリをホームフォルダー（
/Workspace/Users/<your-username>/...）内のGitフォルダーにクローンします。リポジトリのクローンを参照してください。クローンは個人用Git認証情報を使用し、フォルダーを所有します。このオプションでは、ロールは独自のGit資格情報を必要としません。 - ロールにフォルダへのアクセスを許可します ( ランの実行可能 、またはロールがファイルを変更する必要がある場合は 編集可能 )。これにより、ロールとして作業できます。
- ロールを割り当ててから、フォルダーで変更してください。ロールのデータアクセスが有効です。
- ユーザーIDに戻り、その後、「commitしてプッシュ」してください。commitは個人の
git_usernameとgit_emailを使用します。
ユーザーIDからロールにフォルダーを共有しているため、ワークスペース資産共有制御は、このオプションに影響しません。これらの制御は、ロールが資産を外部に共有することのみを制限します。
オプション 2: 役割のホームフォルダーにクローンを作成し、ユーザーIDと共有します。
- ロールを引き受けて、リポジトリをロールのホームフォルダーのGitフォルダーにクローンします。クローンはロールのGit資格情報を使用します。これには少なくとも読み取りアクセス権が必要です。
- ロールとして機能している間は、ユーザー ID にフォルダーへのアクセス権を付与します（ 編集可能）。
- ロールとして変更を行ってください。ロールのデータアクセスは有効です。
- ユーザーIDに切り替えます。ユーザーアクセスを許可したため、フォルダーに到達できます。そのため、個人認証情報を使用してcommitしてプッシュします。このcommitでは、個人の
git_usernameとgit_emailを使用します。
ロールがフォルダをユーザーIDに外部共有しているため、ロールがワークスペースアセット共有コントロールの拒否リストにある場合、このオプションは機能しません。これらのロールにはオプション1を使用してください。
ロールとしてcommit
このアプローチでは、ロールとして機能しながらclone、author、commitのすべてを実行します。これは最もシンプルなワークフローです。フォルダを共有したり、commitのためにIDを切り替えたりする必要はありません。ワークスペースUIが単一のアクションでcommitとpushを行うため、ロールのGit認証情報に書き込みアクセス権が必要です。
- ロールを割り当て。
- リポジトリを Git フォルダにクローンします。ロールとして操作しているため、クローンにはロールの Git 資格情報が使用されます。
- 変更を加えてから、commitしてプッシュしてください。そのcommitは、ロールの
git_usernameとgit_emailを使用します。
このアプローチを選択する前に、これらの影響を考慮してください：
- **帰属はロールレベルで行われます。** Gitプロバイダーでのcommitは、個々の作成者ではなく、ロールのGit IDを表示します。Databricks監査Logsは、ワークスペースUIを通じて行われたcommitについて、
identity_metadata.run_as(ロール) とidentity_metadata.run_by(ユーザー) の両方を記録します。これは、Databricksが個々のユーザーに帰属させない、Webターミナル内のGit CLIから実行される生のGit commitには適用されません。 - ロールの Git 資格情報は共有されており、書き込み可能です。 そのロールを引き受けるすべてのユーザーは、push に同じ資格情報を使用するため、トークンが漏洩または悪用された場合、ロールの ID の下で push、Branch の削除、または commit の作成が可能です。このため、Databricks では読み取り専用のグループ Git 資格情報と、ユーザー ID で commit を行うアプローチを推奨します。書き込み可能な資格情報は、これらのトレードオフを受け入れる場合にのみ使用してください。トークン権限を参照してください。認証情報をロールが必要とするリポジトリのみにスコープします。
変更をプルする
リモート Git リポジトリから変更をプルするには、Git 操作ダイアログで [プル] をクリックします。ノートブックやその他のファイルは、リモート Git リポジトリ内の最新バージョンに自動的に更新されます。リモート リポジトリから取得された変更が Databricks のローカルの変更と競合する場合は、マージの競合を解決します。
アップストリームの変更をプルする Git 操作により、ノートブックの状態がクリアされます。「受信した変更によってノートブックの状態がクリアされる」を参照してください。
Gitフォルダで共同作業する
Databricks Git フォルダーはワークスペース内の埋め込み Git クライアントとして動作し、Git ベースのソース管理とバージョン管理を通じて共同作業を行うことができます。効果的なチームコラボレーションのために:
- 各チーム メンバーには、リモート Git リポジトリにマップされた独自の Git フォルダーがあり、そこで各自の開発ブランチで作業します。
- 各 Git フォルダーに対して Git 操作を実行できるのは 1 人のユーザーのみです。複数のユーザーが同じフォルダーに対して Git 操作を実行すると、1 人のユーザーが意図せず全員のブランチを切り替えてしまうなど、ブランチ管理の問題が発生する可能性があります。
Git フォルダ構成を共同作業者と共有するには:
- [共有] をクリックします。
- 「リンクをコピー」をクリックして Git フォルダーを作成します 。
- URL を共同作業者に送信します。
- 共同作業者が URL を開くと、Git フォルダー構成が事前に入力されたダイアログが表示されます。
- 「Git フォルダーの作成」を クリックして、リポジトリを現在の作業フォルダーの下の自分のワークスペースに複製します。
ブランチのマージ
Databricks Git フォルダーのマージ関数は、 git mergeを使用して、あるブランチのコミット履歴を別のブランチに結合します。Git 初心者の場合、強制プッシュを必要とせず、コミット履歴を書き換えることもないため、Databricks では rebase ではなく merge を使用することをお勧めします。
ブランチを別のブランチにマージするには、ケバブメニューをクリックして、 マージ を選択します。
- マージの競合がある場合は、Git フォルダー UI で解決します。
- 競合がない場合、マージは
git pushを使用してリモート Git リポジトリにプッシュされます。
マージ競合の解決
マージ競合は、プル、リベース、マージ操作中など、Git が異なるソースからのファイルの同じ行への変更を自動的に調整できない場合に発生します。
マージの競合を解決するには、競合するファイルと解決オプションを表示する Git フォルダー UI を使用します。
- 手動でファイルを編集し、保持する変更を選択します。
- 1 つのバージョンを完全に受け入れるには、 「現在のすべての変更を保持」 または 「受信したすべての変更を取得」 を選択します。
- 操作を中止し、競合する変更を破棄して再試行してください。
手動で競合を解決する
手動での競合解決により、どの競合行を受け入れるかを決定できます。競合を解決するには、ファイルの内容を直接編集します。
競合を解決するには、保持するコード行を選択し、Git マージ競合マーカーを含む他のすべての行を削除します。完了したら、[ 解決済みとしてマーク] を選択します。
マージの競合を解決するときに間違った選択をした場合は、 [中止] をクリックしてプロセスを中止し、すべてを元に戻します。すべての競合が解決されたら、 「マージを続行」 または 「リベースを続行」 をクリックして競合を解決し、操作を完了します。
ブランチをリベースする
Databricks Git フォルダーの rebase 関数は、 git rebaseを使用して、ターゲット ブランチの上にコミットを再適用し、線形履歴を作成することで、あるブランチから別のブランチに変更を統合します。
ブランチを別のブランチにリベースするには、ケバブ メニューをクリックし、 Rebase を選択してから、ターゲット ブランチを選択します。
- リベース後、Git フォルダーは
git commitとgit push --forceを実行してリモート リポジトリを更新します。 - Rebase はコミット履歴を書き換えるため、同じリポジトリで作業している共同作業者にとってバージョン管理の問題が発生する可能性があります。
ブランチをリセットする
Git フォルダー UI から Git リセットを実行します。この操作は、 git reset --hardとgit push --forceを組み合わせたものと同じです。
Git リセットは、ブランチの内容と履歴を別のブランチの最新の状態に置き換えます。編集内容が上流ブランチと競合し、上流ブランチにリセットしたときにそれらの編集内容が失われても構わない場合にこれを使用できます。git reset --hardについての詳細をご覧ください。
リモートブランチにリセットする
このシナリオの git reset を使用すると、次のようになります。
- 選択したブランチ (
feature_aなど) を別のブランチ (mainなど) にリセットした - また、アップストリーム (リモート) ブランチ
feature_aを main にリセットします。
リセットすると、ブランチのローカルバージョンとリモートバージョンの両方で、コミットされていない変更とコミットされた変更がすべて失われます。
ブランチをリモートブランチにリセットするには:
-
Git フォルダー UI の [ブランチ ] メニューで、リセットするブランチを選択します。
-
リセット を選択する
ケバブメニュー。
-
リセットするブランチを選択し、 「実行Gitリセット」 をクリックします。
スパースチェックアウトモードを設定してください
スパース チェックアウトは、Databricks 内のリモート リポジトリのディレクトリのサブセットのみを複製して操作できるようにするクライアント側の設定です。これは、リポジトリのサイズが Databricks でサポートされている制限を超える場合に特に便利です。
新しいリポジトリを複製するときにスパース チェックアウト モードを有効にします。スパースチェックアウトモードは、一度有効にすると無効にすることはできません。
-
「Git フォルダーの作成」 ダイアログで、 スパース チェックアウト モード を有効にします。
![[Git フォルダの追加] ダイアログの [スパース チェックアウト] オプション。](/gcp/ja/assets/images/sparse-checkout-option-a15124edda5dea8085f8545f304079f7.png)
-
[コーンパターン] ボックスで、必要なコーンチェックアウトパターン を指定します。 複数のパターンを改行で区切ります。
コーンパターンのしくみ
スパース チェックアウト モードでのコーン パターンの動作を理解するには、リモート リポジトリ構造を表す次の図を参照してください。
スパースチェックアウトモード を選択しても、コーンパターンを指定しない場合は、デフォルトのコーンパターンが適用されます。これにはルート内のファイルのみが含まれ、サブディレクトリは含まれないため、リポジトリ構造は次のようになります。
スパースチェックアウトコーンパターンをparent/child/grandchildに設定すると、 grandchildディレクトリのすべての内容が再帰的に含められます。/parent 、 /parent/child 、およびルート ディレクトリの直下にあるファイルも含まれます。次の図のディレクトリ構造を参照してください。
除外動作 ( ! ) は、Git コーン パターン構文ではサポートされていません。
スパース チェックアウトの設定を変更する
リポジトリを作成した後、 [設定] > [詳細設定] > [コーン パターン] からスパース チェックアウト コーン パターンを編集します。
次の動作に注意してください。
-
コーンパターンからフォルダーを削除すると、コミットされていない変更がない場合、Databricks から削除されます。
-
スパース チェックアウト コーン パターンを編集してフォルダーを追加すると、追加のプルを必要とせずにフォルダーが Databricks に追加されます。
-
フォルダー内にコミットされていない変更がある場合、スパース チェックアウト パターンを変更してフォルダーを削除することはできません。
たとえば、フォルダー内のファイルを編集して変更をコミットしない場合、そのフォルダーを除外するようにスパース チェックアウト パターンを変更しようとすると、パターンは受け入れられますが、フォルダーは削除されません。そのフォルダーを含めるようにパターンを元に戻し、変更をコミットしてから、新しいパターンを再度適用する必要があります。
スパースチェックアウトで変更を加える
既存のファイルを編集し、Git フォルダーからコミットしてプッシュします。新しいファイルのフォルダーを作成するときは、そのリポジトリに指定したコーン パターンにそれらを含めます。
コーン パターンの外側に新しいフォルダーを含めると、コミットおよびプッシュ操作中にエラーが発生します。これを修正するには、コミットしてプッシュしようとしている新しいフォルダーを含めるようにコーン パターンを編集します。
スパースチェックアウトの制限
- スパース チェックアウトは、4 GB を超える Azure DevOps リポジトリでは機能しません。
- スパース チェックアウトを有効にして作成されたリポジトリのスパース チェックアウトを無効にすることはできません。
Gitフォルダをプログラムで管理する
API を使用して Git フォルダーを管理するには、 Repos API リファレンスを参照してください。
Gitフォルダを削除する
ワークスペースから Git フォルダーを削除するには:
- Git フォルダーを右クリックし、 [ゴミ箱に移動] を選択します。
- 「確認してゴミ箱へ移動」を クリックします。
次のステップ
- Databricks を Git プロバイダーに接続するための認証を設定します。「Git プロバイダーを Databricks に接続する」を参照してください。
- Git フォルダーのサイズ制限やその他の制約について説明します。Databricks Git フォルダーの制限とリファレンスを参照してください。
- Git 統合のワークスペース レベルの設定を構成します。「Git フォルダーの Git 統合の構成」を参照してください。