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

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

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

1. サイドバーで [ ワークスペース ] を選択し、Git リポジトリ クローンを作成するフォルダーにブラウザーで移動します。

2. ワークスペースの右上にある [追加 ] の右側にある下矢印をクリックし、ドロップダウンから [Git フォルダー ] を選択します。

   

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

   • クローンを作成する Git リポジトリの URL (形式) https://example.com/organization/project.git
   • クローンするリポジトリの Git プロバイダー。 オプションには、GitHub、GitHub Enterprise、GitLab、Azure DevOps (Azure Repos) が含まれます
   • クローンされたリポジトリの内容が含まれるワークスペース内のフォルダーの名前
   • リポジトリのディレクトリのサブセットのみがクローンされる スパース チェックアウトを使用するかどうかは、コーン パターンを使用して指定されます。これは、リポジトリが Databricks でサポートされている 制限よりも大きい場合に便利です。

   

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

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

Databricks Git フォルダーは、ワークスペースに埋め込まれた Git クライアントとして効果的に動作するため、ユーザーは Git ベースのソース管理とバージョン管理を使用して共同作業を行うことができます。 チームのコラボレーションをより効果的にするには、 自分の開発ブランチで作業するユーザーごとに、リモート Git リポジトリにマップされた個別の Databricks Git フォルダーを使用します 。 複数のユーザーが Git フォルダーにコンテンツを投稿できますが、プル、プッシュ、コミット、ブランチ切り替えなどの Git 操作を実行する必要があるのは 、指定された 1 人の ユーザーだけです。 複数のユーザーが Git フォルダーに対して Git 操作を実行すると、ユーザーがブランチを切り替えて、そのフォルダーの他のすべてのユーザーに対して意図せずにブランチを切り替えるなど、ブランチ管理が困難になり、エラーが発生しやすくなります。

Git フォルダーを共同作業者と共有するには、Databricks ワークスペースの上部にあるバナーで [リンクのコピー] をクリックして Git フォルダーを作成します 。 このアクションにより、URL がローカル クリップボードにコピーされ、別のユーザーに送信できます。 受信者のユーザーがその URL をブラウザーに読み込むと、ワークスペースに移動し、同じリモート Git リポジトリから複製された独自の Git フォルダーを作成できます。 UIに [Gitフォルダの作成 ]モーダルダイアログが表示され、独自のGitフォルダから取得した値が事前に入力されます。 モーダルの青い [Git フォルダーの作成 ] ボタンをクリックすると、Git リポジトリが現在の作業フォルダーの下のワークスペースにクローンされ、直接操作できるようになります。

共有ワークスペースで他のユーザーの Git フォルダーにアクセスする場合は、上部のバナーで [ Git フォルダーを作成 ] をクリックします。このアクションにより、[ Git フォルダーの作成 ] ダイアログが開き、それをサポートする Git リポジトリの構成が事前に入力されます。

important

現在、Git CLI を使用して Git フォルダで Git 操作を実行することはできません。クラスタリングのWebターミナルを通じて を使用してGit リポジトリをクローンすると、ファイルはCLIDatabricks UIに表示されません。

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 フォルダー内のローカル ブランチを完全に削除するには、リポジトリを削除します。

important

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

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

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

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

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

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

注記

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

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

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

important

アップストリームの変更を取り込む 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 にリセットします。

important

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

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

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 を使用します。