次の方法で共有

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

  • [アーティクル]

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

バナーの [Git フォルダーへのリンクのコピー] をクリックして、そのフォルダーの Git リポジトリ構成を Databricks 組織内の別のユーザーと共有します

共有ワークスペース内の他のユーザーの Git フォルダーにアクセスする場合は、上部のバナーにある [Git フォルダーの作成] をクリックします。 この操作により、[Git フォルダーの作成] ダイアログが開き、元となる Git リポジトリの構成が事前に設定されます。

別のユーザーの Git フォルダーを表示する場合は、バナーの [Git フォルダーの作成] ボタンをクリックして、自分自身のワークスペースにそのフォルダーのコピーを作成します

重要

現時点では、Git CLI を使って Git フォルダーで Git 操作を実行することはできません。 クラスターの Web ターミナルを介して CLI を使用して Git リポジトリをクローンした場合、ファイルは Azure 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 リポジトリにプッシュするボタン。

ハード リセット、マージ、リベースなどの他の Git ブランチ操作から選ぶには、右上の Kebab メニュー ケバブをクリックします。

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

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

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

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

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

異なるブランチに切り替える

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

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

重要

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

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

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

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

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

既定のブランチ (main ブランチなど) にコミットする権限がない場合は、新しいブランチを作成し、お使いの Git プロバイダー インターフェイスを使用して pull request (PR) を作成して、既定のブランチにマージします。

Note

  • ノートブックがソース ファイル形式 (.py、.scala、.sql、.r) で保存されているとき、既定ではノートブックの出力はコミットに含まれません。 IPYNB 形式を使用してノートブック出力をコミットする方法の詳細については、「IPYNB ノートブック出力成果物コミットの制御」を参照してください

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

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

重要

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

ブランチをマージする

Git 操作ダイアログの右上にある Kebab メニュー ケバブから Git の [マージ] 操作を選んで、それにアクセスします。

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

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

Rebaseブランチを別のブランチで

Git 操作ダイアログの右上にある Kebab メニュー ケバブ メニューから Git の [リベース] 操作を選んで、それにアクセスします。

リベースにより、ブランチのコミット履歴が変更されます。 git rebase では、git merge と同様に、あるブランチの変更が別のブランチに統合されます。 リベースでは次の処理が実行されます。

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

警告

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

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

ブランチを別のブランチでリベースするには、次の手順を実行します。

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

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

    ケバブ メニューの Git リベース関数。

  3. リベースするブランチを選択します。

    リベース操作によって、ここで選択したブランチの変更が現在のブランチに統合されます。

Databricks Git フォルダーで git commit と git push --force が実行されて、リモート Git リポジトリが更新されます。

マージの競合を解決する

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

Git プルの間にコミットされていない変更によって発生することがよくあるマージ競合を示すアニメーション GIF

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

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

  • Git フォルダー UI を使って競合を解決します。
  • Git 操作を中止し、競合するファイルの変更を手動で破棄して、Git 操作をもう一度試します。

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

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

現在のすべてのものを保持するか受信した変更を受け入れる

現在または受信したすべての変更を保持したいだけであることがわかっている場合は、ノートブック ウィンドウのファイル名の右側にある kebab をクリックし、[Keep all current changes] (現在のすべての変更を保持) または [Take all incoming changes] (受信したすべての変更を受け入れる) を選択します。 同じラベルのボタンをクリックして変更をコミットし、競合を解決します。

マージ競合解決のドロップダウン オプションが表示されている、Databricks ノートブック UI のペイン

ヒント

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

手動で競合を解決する

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

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

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

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

Git reset

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

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

アップストリーム (リモート) ブランチにリセットする

このシナリオでは、git reset を使用します。

  • 選択したブランチ (たとえば、feature_a) を異なるブランチ (たとえば、main) にリセットします。
  • また、アップストリーム (リモート) ブランチ feature_a をメインにリセットします。

重要

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

ブランチをリモート ブランチにリセットするには、次の手順を実行します。

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

    Git フォルダー UI のブランチ セレクター。

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

    ケバブ メニューの Git リセット操作。

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

    Git reset --hard のダイアログ。

スパース チェックアウト モードを構成する

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

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

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

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

    [Git フォルダーの追加] ダイアログのスパース チェックアウト オプション。

  3. [Cone patterns](円錐パターン) ボックスで、目的の円錐チェックアウト パターンを指定します。 複数のパターンを改行で区切ります。

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

円錐パターンのしくみ

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

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

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

スパース チェックアウト: 既定の円錐パターン。

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

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

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

Note

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

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

リポジトリが作成された後で、スパース チェックアウト円錐パターンは、[設定] > [詳細設定] > [Cone patterns](円錐パターン) から編集できます。

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

  • 円錐パターンからフォルダーを削除すると、コミットされていない変更がない場合は、そのフォルダーが 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 を使います。