Databricks Git フォルダーで Git 操作を実行する

この記事では、Git フォルダーを使用して Databricks ワークスペースで一般的な Git 操作 (複製、分岐、コミット、プッシュなど) を実行する方法について説明します。

リモート Git リポジトリに接続されているリポジトリをクローンする

Databricks UI または Web ポータルを使用してGitフォルダーを作成できます。

注記

• Git フォルダーを作成する親フォルダーに対するCAN MANAGE権限が必要です。
• ワークスペースには Git 資格情報が設定されている必要があります。「Git 資格情報を構成し、リモート リポジトリを Databricks に接続する」を参照してください。

UIからクローン

1. サイドバーで 「ワークスペース」 を選択し、Git リポジトリのクローンを作成するフォルダーを参照します。

2. [作成] > [Git フォルダー] をクリックします。

   

3. 「Git フォルダーの作成 」ダイアログで、以下の情報を入力します。

フィールド	説明
GitリポジトリのURL	クローンを作成する Git リポジトリの URL (形式) https://example.com/organization/project.git
Gitプロバイダー	クローンするリポジトリの Git プロバイダー。 オプションには、GitHub、GitHub Enterprise、GitLab、Azure DevOps (Azure Repos) が含まれます
Gitフォルダ名	クローンされたリポジトリの内容が含まれるワークスペース内のフォルダーの名前
スパースチェックアウト	リポジトリのディレクトリのサブセットのみをクローンするスパース チェックアウトを使用するかどうかを、コーン パターンを使用して指定します。これは、リポジトリが Databricks でサポートされている制限よりも大きい場合に役立ちます。
Git CLI を使用する（ベータ版）	Databricks ターミナルから標準の Git コマンドを直接実行できるようになります。これにより、コミット前フック、Git サブモジュール、大容量ファイル ストレージ (LFS) などの高度な操作にアクセスできるようになります。「Git CLI コマンドの使用 (ベータ版)」を参照してください。

4. 「Git フォルダを作成 」をクリックします。リモート リポジトリの内容は Databricks リポジトリに複製され、ワークスペースを通じてサポートされている Git 操作を使用して作業を開始できます。

Webターミナルからクローンする

Web ターミナルから直接CLIアクセスしてGitフォルダーを作成することもできます。

1. Webポータルにアクセスします。 Databricks Web ポータルの実行シェル コマンドを参照してください。

2. /Workspaceの親ディレクトリに移動します:

   Bash

   cd /Workspace/Users/<your-email>/<project>

注記

/Reposまたは既存の Git フォルダー内にGit CLI アクセスを使用して Git フォルダーを作成することはできません。

3. リポジトリをクローンします:

   Bash

   git clone <remote-url>

   git cloneコマンドは、ワークスペースで構成された Git 資格情報を使用します。「Git 資格情報を構成し、リモート リポジトリを Databricks に接続する」を参照してください。

4. ブラウザを更新すると、ワークスペース ファイル ブラウザに新しいフォルダが表示されます。

Git CLI コマンドを使用する (ベータ版)

備考

ベータ版

この機能はベータ版です。

Git CLI アクセスを備えた Git フォルダーを使用すると、Databricks ターミナルから直接標準の Git コマンドを実行できます。あなたはできる：

• git stash 、 git pull --force 、 git rebase -iを含む任意の Git コマンドを実行します。
• コミット前のフックにリンティングとコードスキャンを統合します。
• 標準の Git フォルダーの 2 GB のメモリと 4 GB のディスク制限を超えるリポジトリを操作します。
• Git サブモジュールと Large File Storage (LFS) を使用します。
• リモート リポジトリにプッシュする前に、複数のコミットをローカルでステージングします。

Git CLIアクセスを使用するには、ワークスペースの環境バージョン 4 以降でサーバレス コンピュートが有効になっている必要があります。

Git CLI アクセスで Git フォルダを作成する

CLI アクセスで Git フォルダーを作成するには:

• Web ポータルを使用すると、複製したリポジトリは自動的にGit CLIアクセスできるようになります。
• UIを使用する場合は、Git フォルダーを作成するときに、 Git CLI プレビューの使用 を有効にする必要があります。

CLIアクセスでGitフォルダーを作成した後、Web ターミナルから標準のGitコマンドを実行します。

Bash

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 フォルダーには次の制限があります。

• リモート URL 許可リストが有効になっているワークスペースでは、Git CLI 機能を使用できません。
• Git CLI コマンドは、ノートブックの出力のコミットをブロックする管理者設定を無視します。
• Repos API は、CLI アクセスが可能な Git フォルダーではサポートされていません。
• 既存の Git フォルダーに対して Git CLI アクセスを有効にすることはできません。

Git CLI 操作のトラブルシューティング

• ターミナルですべての操作の資格情報が要求されます : ワークスペースで Git CLI 機能が有効になっていません。プレビューが有効になっていることを確認するには、ワークスペース管理者に問い合わせてください。
• CLI アクセスを有効にできません : リモート URL 許可リストを持つワークスペースでは Git CLI 機能を使用できません。ワークスペースのネットワーク構成を確認するには、ワークスペース管理者に問い合わせてください。
• Git 操作が権限エラーで失敗しました : 親フォルダーに対するCAN MANAGE権限があること、およびワークスペースの Git 資格情報が有効であることを確認してください。「Git 資格情報を構成し、リモート リポジトリを Databricks に接続する」を参照してください。

ベスト プラクティス: Git フォルダーでの共同作業

Databricks Git フォルダーはワークスペース内の埋め込み Git クライアントとして動作し、Git ベースのソース管理とバージョン管理を通じて共同作業を行うことができます。効果的なチームコラボレーションのために:

• 各チーム メンバーには、リモート Git リポジトリにマップされた独自の Git フォルダーがあり、そこで各自の開発ブランチで作業します。
• 各 Git フォルダーに対して Git 操作を実行できるのは 1 人のユーザーのみです。複数のユーザーが同じフォルダーに対して Git 操作を実行すると、1 人のユーザーが意図せず全員のブランチを切り替えてしまうなど、ブランチ管理の問題が発生する可能性があります。

Git フォルダ構成を共同作業者と共有するには:

1. Databricks ワークスペースの上部にあるバナーで [リンクをコピーして Git フォルダーを作成します] をクリックします。
2. URL を共同作業者に送信します。
3. 共同作業者が URL を開くと、Git フォルダーの設定が事前に入力された 「Git フォルダーの作成」 ダイアログが表示されます。
4. 「Git フォルダーの作成」を クリックして、リポジトリを現在の作業フォルダーの下の自分のワークスペースに複製します。

別のユーザーから Git フォルダーをコピーするには:

1. 共有ワークスペース内の他のユーザーの Git フォルダーを開きます。
2. 上部のバナーにある 「Git フォルダーの作成」を クリックします。Git リポジトリ構成が事前に入力された状態で、 Git フォルダーの作成 ダイアログが開きます。
3. 「Git フォルダーの作成」 をクリックして、リポジトリを自分のワークスペースに複製します。

Git ダイアログにアクセスする

Git ダイアログには、ノートブックまたは Databricks Git フォルダー ブラウザーからアクセスできます。

• ノートブックで、現在の Git ブランチを識別するノートブックの名前の横にあるボタンをクリックします。

  

• Databricks Git フォルダー ブラウザーで、リポジトリ名の右側にあるボタンをクリックします。 リポジトリ名を右クリックして、メニューから [ Git... ] を選択することもできます。

  

全画面表示のダイアログが表示され、Git 操作を実行できます。

1. 現在の作業ブランチ。 ここで他のブランチを選択できます。 他のユーザーがこの Git フォルダーにアクセスできる場合、ブランチを変更すると、同じワークスペースを共有している場合、そのユーザーのブランチも変更されます。 この問題を回避するための推奨される ベスト プラクティス を参照してください。
2. 新しいブランチを作成するためのボタン。
3. 現在のブランチにチェックインされたファイル資産とサブフォルダーのリスト。
4. Git プロバイダーに移動し、現在のブランチ履歴を表示するボタン。
5. リモート Git リポジトリからコンテンツを取得するためのボタン。
6. コミット メッセージと、変更の拡張説明(オプション)を追加するテキスト ボックス。
7. 作業ブランチに作業をコミットし、更新されたブランチをリモートの Git リポジトリにプッシュするボタン。

右上の ケバブをクリックして、ハードリセット、マージ、リベースなどの追加の Git ブランチ操作から選択します。

これは、ワークスペースの Git フォルダーで Git 操作を実行するためのホームです。 ユーザー インターフェイスに表示される Git 操作に制限されます。

新しいブランチを作る

既存のブランチに基づいて新しいブランチを Git ダイアログから作成できます。

別のブランチに切り替える

Git ダイアログのブランチドロップダウンを使用して、別のブランチに切り替え (チェックアウト) できます。

現在のブランチのコミットされていない変更は、コミットされていない変更が新しいブランチのコードと競合しない限り、新しいブランチに引き継がれ、コミットされていない変更として表示されます。コミットされていない変更を引き継ぐ予定がない場合は、ブランチの切り替えの前または後の変更を破棄します。

ブランチのローカル バージョンは、リモート ブランチが削除されてから最大 30 日間、関連付けられた Git フォルダーに存在し続けることができます。Git フォルダー内のローカル ブランチを完全に削除するには、リポジトリを削除します。

重要

ブランチを切り替えると、新しいブランチにこれらのアセットが含まれていないワークスペースアセットが削除されることがあります。現在のブランチに戻すと、削除されたアセットが新しい ID と URL で再作成されます。この変更は元に戻すことはできません。

Git フォルダーからアセットを共有またはブックマークした場合は、切り替える前にアセットが新しいブランチに存在することを確認してください。

変更をコミットしてリモートGitリポジトリにプッシュする

新しいノートブックやファイルを追加したり、既存のノートブックやファイルに変更を加えたりすると、Git フォルダーの UI で変更が強調表示されます。

変更に必要なコミット メッセージを追加し、[ コミットとプッシュ ] をクリックして、これらの変更をリモート Git リポジトリにプッシュします。

デフォルト ブランチ ( main ブランチなど) にコミットするアクセス許可がない場合は、新しいブランチを作成し、 Git プロバイダーのインターフェイスを使用してプル要求 (PR) を作成し、それをデフォルト ブランチにマージします。

注記

• ノートブック がソース ファイル形式 (.py、 .scala、 .sql、 .r) で保存されている場合、ノートブック 出力は Default によるコミットに含まれません。 ipynb 形式を使用したコミット ノートブック 出力に関する情報については、「ipynb ノートブック 出力の制御 アーティファクト コミット」を参照してください。

リモート Git リポジトリから変更をプルする

リモート Git リポジトリから変更をプルするには、Git 操作ダイアログで [プル ] をクリックします。 ノートブックやその他のファイルは、リモートの Git リポジトリで自動的に最新バージョンに更新されます。 リモート リポジトリからプルされた変更が Databricks のローカル変更と競合する場合は、 マージの競合を解決する必要があります。

重要

アップストリームの変更を取り込む Git 操作は、ノートブックの状態をクリアします。 詳細については、「 受信変更によるノートブックの状態のクリア」を参照してください。

ブランチのマージ

Git Merge 操作にアクセスするには、Git 操作ダイアログの右上にある ケバブから選択します。

Databricks Git フォルダーのマージ関数は、 git mergeを使用して 1 つのブランチを別のブランチにマージします。 マージ操作は、1 つのブランチから別のブランチにコミット履歴を結合する方法です。唯一の違いは、これを達成するために使用する戦略です。 Git の初心者には、ブランチへの強制的なプッシュを必要とせず、コミット履歴を書き換えないため、merge (リベースよりも) を使用することをお勧めします。

• マージの競合がある場合は、Git フォルダー UI で解決します。
• 競合がない場合、マージは git pushを使用してリモート Git リポジトリにプッシュされます。

ブランチを別のブランチにRebaseする

Git Rebase 操作にアクセスするには、Git 操作ダイアログの右上にある ケバブ メニューから選択します。

リベースすると、ブランチのコミット履歴が変更されます。 git mergeと同様に、git rebase は 1 つのブランチから別のブランチへの変更を統合します。Rebase は次のことを行います。

1. 現在のブランチのコミットを一時的な領域に保存します。
2. 現在のブランチを選択したブランチにリセットします。
3. 現在のブランチに以前に保存された個々のコミットを再適用すると、両方のブランチからの変更を組み合わせた線形履歴が作成されます。

警告

リベースを使用すると、同じリポジトリで作業しているコラボレーターのバージョン管理の問題が発生する可能性があります。

一般的なワークフローは、メイン ブランチに機能ブランチをリベースすることです。

ブランチを別のブランチにリベースするには:

1. Git フォルダー UI の [ブランチ ] メニューから、リベースするブランチを選択します。

2. ケバブメニューから リベース を選択します。

   

3. リベースしたいブランチを選択してください。

   リベース操作は、ここで選択したブランチからの変更を現在のブランチに統合します。

Databricks Git フォルダーは、リモート Git リポジトリを更新するために git commit と git push --force を実行します。

マージ競合の解決

マージの競合は、2 人以上の Git ユーザーがファイルの同じ行への変更を共通のブランチにマージしようとし、Git が適用する「正しい」変更を選択できない場合に発生します。 マージの競合は、ユーザーが別のブランチからコミットされていない変更を含むブランチに変更をプルまたはマージしようとしたときにも発生する可能性があります。

プル、リベース、マージなどの操作によってマージの競合が発生した場合、Git フォルダーの UI には、競合のあるファイルの一覧と、競合を解決するためのオプションが表示されます。

主に 2 つのオプションがあります。

• Git フォルダー UI を使用して競合を解決します。
• Git 操作を中止し、競合するファイルの変更を手動で破棄して、Git 操作を再試行してください。

Git フォルダー UI を使用してマージ競合を解決する場合は、エディターで競合を手動で解決するか、すべての受信または現在の変更を保持するかを選択する必要があります。

すべての変更を最新の状態に保つ か 、新しい変更を受け取る

現在の変更または新しい変更 をすべて 保持することがわかっている場合は、ノートブック ウィンドウでファイル名の右側にあるケバブをクリックし、[ 現在のすべての変更を保持する ] または [ すべての受信する変更を取得する ] を選択します。 同じラベルのボタンをクリックして、変更をコミットし、競合を解決します。

ヒント

どのオプションを選択すべきか混乱していますか? 各オプションの色は、ファイルに保持されるそれぞれのコード変更と一致します。

コンフリクトを手動で解決する

手動の競合解決により、競合する行のうち、どの行をマージで受け入れるかを決定できます。 マージ競合の場合は、競合のあるファイルの内容を直接編集して競合を解決します。

競合を解決するには、保持するコード行を選択し、Git マージ競合マーカーを含む他のすべての行を削除します。完了したら、[ 解決済みとしてマーク] を選択します。

マージ競合の解決時に間違った選択をしたと判断した場合は、[ 中止 ] ボタンをクリックしてプロセスを中止し、すべてを元に戻します。 すべての競合が解決されたら、[ Continue Merge] または [Continue Rebase ] オプションをクリックして競合を解決し、操作を完了します。

Git reset

Databricks Git フォルダーでは、Databricks UI 内で Git reset を実行できます。 Databricks Git フォルダーでの Git リセットは、 git reset --hard と git push --forceを組み合わせたものと同じです。

リセットGit、ブランチの内容と履歴が別のブランチの最新の状態に置き換えられます。これは、編集内容がアップストリームブランチと競合している場合に使用でき、アップストリームブランチにリセットしたときにそれらの編集内容が失われても問題ありません。詳しくは、 git reset –hardをご覧ください。

アップストリーム (リモート) ブランチへのリセット

このシナリオの git reset を使用すると、次のようになります。

• 選択したブランチ ( feature_aなど) を別のブランチ ( mainなど) にリセットした
• また、アップストリーム (リモート) ブランチ feature_a を main にリセットします。

重要

リセットすると、ブランチのローカルバージョンとリモートバージョンの両方で、コミットされていない変更とコミットされた変更がすべて失われます。

ブランチをリモートブランチにリセットするには:

1. Git フォルダー UI の [ブランチ ] メニューで、リセットするブランチを選択します。

   

2. ケバブメニューから 「リセット 」を選択します。

   

3. リセットするブランチを選択します。

   

スパースチェックアウトモードを設定してください

スパース チェックアウトは、Databricks 内のリモート リポジトリのディレクトリのサブセットのみを複製して操作できるクライアント側の設定です。これは、リポジトリのサイズが Databricks でサポートされている 制限を超えている場合に特に便利です。

スパース チェックアウト モードは、新しいリポジトリを追加 (クローン作成) するときに使用できます。

1. [ Git フォルダーの追加 ] ダイアログで、[ 詳細設定] を開きます。

2. スパースチェックアウトモード を選択します。

   

3. [コーンパターン] ボックスで、必要なコーンチェックアウトパターン を指定します。 複数のパターンを改行で区切ります。

現時点では、Databricks のリポジトリのスパース チェックアウトを無効にすることはできません。

コーンパターンのしくみ

スパース チェックアウト モードでのコーン パターンの動作を理解するには、リモート リポジトリの構造を表す次の図を参照してください。

スパース チェックアウト モード を選択し、コーンパターンを指定しない場合は、既定のコーンパターンが適用されます。これには、ルート内のファイルのみが含まれ、サブディレクトリは含まれません。その結果、次のような リポジトリ構造になります。

スパース チェックアウト コーン パターンを parent/child/grandchild に設定すると、 grandchild ディレクトリのすべてのコンテンツが再帰的に含まれます。 /parent、/parent/child、およびルートディレクトリのすぐにあるファイルも含まれます。次の図のディレクトリ構造を参照してください。

改行で区切られた複数のパターンを追加できます。

注記

除外動作 (!) は、Git コーンパターン構文ではサポートされていません。

スパース チェックアウトの設定を変更する

リポジトリが作成されると、スパース チェックアウト コーン パターンは [設定] > [詳細設定] > [コーン パターン ] から編集できます。

次の動作に注意してください。

• コーンパターンからフォルダーを削除すると、コミットされていない変更がない場合、Databricks から削除されます。

• スパース チェックアウト コーン パターンを編集してフォルダーを追加すると、追加のプルを必要とせずに Databricks にフォルダーが追加されます。

• スパース チェックアウト パターンを変更して、そのフォルダにコミットされていない変更がある場合、そのフォルダを削除することはできません。

  たとえば、ユーザーがフォルダ内のファイルを編集し、変更をコミットしないとします。 次に、このフォルダを含めないようにスパース チェックアウト パターンを変更しようとします。 この場合、パターンは受け入れられますが、実際のフォルダは削除されません。 そのフォルダを含めるようにパターンを元に戻し、変更をコミットしてから、新しいパターンを再適用する必要があります。

注記

スパース チェックアウト モードを有効にして作成されたリポジトリのスパース チェックアウトを無効にすることはできません。

スパースチェックアウトで変更を加えてプッシュする

既存のファイルを編集し、Git フォルダーからコミットしてプッシュできます。 ファイルの新しいフォルダーを作成するときは、そのリポジトリに指定したコーンパターンにそれらのフォルダーを含めます。

コーンパターンの外側に新しいフォルダーを含めると、コミットおよびプッシュ操作中にエラーが発生します。 これを修正するには、コーンパターンを編集して、コミットしてプッシュしようとしている新しいフォルダーを含めます。

リポジトリ設定ファイルのパターン

コミット出力設定ファイルは 、gitignore パターン と同様のパターンを使用し、次のことを行います。

• 正のパターンにより、一致するノートブックに出力を含めることができます。
• 負のパターンは、一致するノートブックの出力インクルードを無効にします。
• パターンは、すべてのノートブックに対して順番に評価されます。
• 無効なパスや .ipynb ノートブックに解決されないパスは無視されます。

ポジティブパターン: ノートブックのパス folder/innerfolder/notebook.ipynbからの出力を含めるには、次のパターンを使用します。

**/*
folder/**
folder/innerfolder/note*

ネガティブパターン: ノートブックの出力を除外するには、正のパターンが一致しないことを確認するか、構成ファイルの正しい場所に負のパターンを追加します。 ネガティブ(除外)パターンは !で始まります。

!folder/innerfolder/*.ipynb
!folder/**/*.ipynb
!**/notebook.ipynb

スパースチェックアウト制限

スパース チェックアウトは、現在、サイズが 4 GB を超える Azure DevOps リポジトリでは機能しません。

リポジトリを追加し、後でリモートで接続する

Git フォルダーをプログラムで管理および操作するには、 Git フォルダー REST API を使用します。

Gitフォルダを削除する

ワークスペースから Git フォルダーを削除するには:

1. Git フォルダーを右クリックし、 [ゴミ箱に移動] を選択します。
2. 確認のために Git フォルダー名を入力します。
3. 「確認してゴミ箱へ移動」を クリックします。