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

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

リモート Git リポジトリに接続されたリポジトリのクローンを作成する

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

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

    リポジトリ UI を追加します。
  3. 「Git フォルダーの作成」ダイアログで、次の情報を入力します。

    • クローンを作成する Git リポジトリの URL (次の形式) https://example.com/organization/project.git

    • クローンを作成するリポジトリの Git プロバイダー。 オプションには、GitHub、GitHub Enterprise、GitLab、Azure DevOps (Azure Repos) が含まれます

    • クローンされたリポジトリのコンテンツを含むワークスペース内のフォルダーの名前

    • 円錐パターンを使用して指定されたサブディレクトリのみが複製されるスパースチェックアウトを使用するかどうか

    Git フォルダー UI からクローンを作成します。

この段階では、ス パースチェックアウトを使用してリポジトリのディレクトリのサブセットのみをクローンするオプションがあります。 これは、リポジトリが Databricks でサポートされている制限よりも大きい場合に便利です。

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

ベスト プラクティス: Git フォルダーでのコラボレーション

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

重要

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

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

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

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

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

    リポジトリ ブラウザーの Git ダイアログ ボタンと Git メニュー。

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

Databricks ワークスペースで Git 操作を実行するために使用されるダイアログ。
  1. 現在の作業ブランチ。 ここで他のブランチを選択できます。 他のユーザーがこの Git フォルダーにアクセスできる場合、同じワークスペースを共有している場合、ブランチを変更すると、そのユーザーのブランチも変更されます。 この問題を回避するための推奨される ベスト プラクティス を参照してください。

  2. 新しいブランチを作成するためのボタン。

  3. 現在のブランチにチェックインされたファイルアセットとサブフォルダーのリスト。

  4. Git プロバイダーに移動し、現在のブランチ履歴を表示するボタン。

  5. リモート Git リポジトリからコンテンツをプルするボタン。

  6. 変更内容のコミット メッセージとオプションの拡張説明を追加するテキスト ボックス。

  7. 作業を作業ブランチにコミットし、更新されたブランチをリモート Git リポジトリにプッシュするボタン。

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

ブランチ操作用の Git フォルダー ダイアログのドロップダウン メニュー。

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

新しいブランチ を作成する

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

Git ダイアログの新しいブランチ。

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

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

Git ダイアログが別のブランチに切り替わる

重要

Git フォルダー内のブランチをチェックアウトした後、リモート Git リポジトリ上のブランチが他の誰かによって削除される可能性が常にあります。 リモート リポジトリでブランチが削除された場合、ローカル バージョンは関連する Git フォルダーに最大 7 日間存在し続けることができます。 Databricks のローカル ブランチは削除できないため、ローカル ブランチを削除する必要がある場合は、リポジトリも削除して再作成する必要があります。

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

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

変更が強調表示された Git ダイアログ。

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

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

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

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

重要

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

ブランチ のマージ

Git Merge操作にアクセスするには、ケバブメニュー Git 操作ダイアログの右上にある kebab。

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

コミットのマージとリベースの違いの詳細については、 アトラシアンのドキュメントをご覧ください。

  • マージ競合がある場合は、Git フォルダー UI で解決します。

  • 競合がない場合、マージは git push を使用してリモートの Git repo にプッシュされます。

Rebase 別のブランチのブランチ

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

リベースは、ブランチのコミット履歴を変更します。 git mergeと同様に、git rebase はあるブランチから別のブランチに変更を統合します。リベースは次の処理を行います。

  1. 現在のブランチのコミットを一時領域に保存します。

  2. 現在のブランチを選択したブランチにリセットします。

  3. 現在のブランチに以前に保存された個々のコミットを再適用し、両方のブランチからの変更を結合した線形履歴を生成します。

リベースの詳細については、「 git リベース」を参照してください。

警告

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

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

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

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

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

    ケバブメニューのGitリベース機能。
  3. リベースするブランチを選択します。

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

Databricks Git フォルダーはgit commitgit push --forceを実行して、リモート Git リポジトリを更新します。

マージの競合 を解決する

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

git pull 中にコミットされていない変更から生じる一般的なマージ競合を示すアニメーション GIF

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

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

  • Git フォルダー UI を使用して競合を解決します。

  • Git 操作を中止し、競合するファイルの変更を手動で破棄して、Git 操作を再試行します。

Databricks Git フォルダーのフォルダー UI でのマージ競合を示すアニメーション GIF

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

すべての状態を維持する、受信した変更を取り込む

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

Databricks ノートブック UI のウィンドウ (マージ競合解決のドロップダウン オプションを表示)

ヒント

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

競合の手動解決

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

マージ競合の手動解決を示すアニメーション GIF

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

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

Git reset

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

Git リセットは、ブランチの内容と履歴を別のブランチの最新の状態に置き換えます。 これは、編集が上流ブランチと競合している場合に使用でき、上流ブランチにリセットしたときにそれらの編集内容が失われてもかまいません。 git の 'リセット –hard' についてもっと読む

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

このシナリオでは git reset :

  • 選択したブランチ ( feature_aなど) を別のブランチ ( mainなど) にリセットします。

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

重要

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

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

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

    Git フォルダー UI のブランチ セレクター。
  2. ケバブメニューから [リセット ]を選択します。

    ケバブメニューのGitリセット操作。
  3. リセットするブランチを選択します。

    Git リセット --ハードダイアログ。

スパースチェックアウトモード の設定

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

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

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

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

    Git フォルダーの追加ダイアログのスパース チェックアウト オプション。
  3. [円錐パターン] ボックスで、必要な円錐のチェックアウト パターン を指定します。 複数のパターンを改行で区切ります。

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

円錐パターンの仕組み

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

スパースチェックアウトのないリモートリポジトリ構造。

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

スパースチェックアウト:デフォルトのコーンパターン。

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

スパース チェックアウト: 親子フォルダーの円錐パターンを指定します。

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

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

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

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

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

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

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

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

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

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

スパースチェックアウト で変更を行い、プッシュする

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

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

リポジトリ構成ファイル のパターン

コミット出力構成ファイルは、 gitignore パターンに似たパターンを使用し、次のことを行います。

  • 正のパターンにより、一致するノートブックの出力を含めることができます。

  • 負のパターンは、一致するノートブックの出力インクルードを無効にします。

  • パターンは、すべてのノートブックに対して順番に評価されます。

  • 無効なパスまたは .ipynb ノートブックに解決されないパスは無視されます。

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

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

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

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

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

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

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

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