Git フォルダーの作成と管理

このページでは、Azure Databricks Git フォルダーを作成し、複製、分岐、コミット、プッシュなどの一般的な Git 操作を実行する方法について説明します。

このガイドでは、次の Git 操作について説明します。

セットアップと構成 毎日のワークフロー 高度な操作

リポジトリをクローンする

リモート リポジトリを複製すると、Databricks によって、リポジトリの内容を含む Git フォルダーがワークスペースに作成され、変更が追跡されます。 Git フォルダーは、Azure Databricks UI または Web ターミナルを使用して作成できます。

UI から複製する

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

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

  3. [Git フォルダーの作成] ダイアログで、次の情報を指定します。

    フィールド Description
    Git リポジトリ URL 複製する Git リポジトリの URL ( https://example.com/organization/project.git形式)。
    Git プロバイダー クローンするリポジトリの Git プロバイダー。
    Git フォルダー名 複製されたリポジトリの内容を含むワークスペース内のフォルダーの名前。
    スパースチェックアウトモード 円錐パターンを使用してリポジトリのディレクトリのサブセットのみを複製する スパース チェックアウトを使用するかどうか。 これは、リポジトリが サイズ制限を超えている場合に便利です。
  4. [Git フォルダーの作成] をクリックします。 リモート リポジトリの内容はワークスペースに複製され、サポートされている Git 操作の操作を開始できます。 ワークスペースが対象になると、Git CLI アクセス を使用して Git フォルダーが自動的に作成されます。 Git フォルダーが Git CLI アクセスを取得するタイミングを参照してください。

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

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

  1. Web ターミナルにアクセスします。 「Azure Databricks Web ターミナルでシェル コマンドを実行する」を参照してください。

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

    cd /Workspace/Users/<your-email>/<project>
    
  3. リポジトリを複製します。

    git clone <remote-url>
    

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

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

Git CLI コマンドを使用する

重要

この機能は パブリック プレビュー段階です。 ワークスペース管理者は、[プレビュー] ページから Git フォルダーの Git CLI サポートへのアクセスを制御できます。 Azure Databricks プレビューの管理を参照してください。

Git CLI アクセス権を持つ Git フォルダーを使用すると、ノートブック、Web ターミナル、または Genie Code から、サーバーレス コンピューティングで標準の Git コマンドを実行できます。 次のようにすることができます。

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

Git CLI のコンピューティング要件

必要なコンピューティングは、CLI が有効な Git フォルダーの使用方法によって異なります。

Operation コンピューティング要件
UI から CLI アクセス権を持つ Git フォルダーを作成する サーバーレス コンピューティング
Git フォルダー UI から Git 操作を実行する (プル、プッシュ、コミット) サーバーレス コンピューティング
ノートブック、Web ターミナル、または Genie Code から Git CLI コマンドを実行する サーバーレス コンピューティング (環境バージョン 5 以上) またはクラシック コンピューティング (Databricks Runtime 17.0 以降)

サーバーレス コンピューティングを有効にするには、「 サーバーレス コンピューティングへの接続」を参照してください。

Git プロバイダーでプライベート ネットワーク接続が必要な場合は、「 ネットワーク接続の構成」を参照してください。

SSH トンネル経由でコンピューティングAzure Databricks接続されている IDE またはターミナルから Git CLI コマンドを実行することもできます。 これは、ターミナルの Git CLI コマンドのコンピューティング要件を満たしています。

Git フォルダーが Git CLI にアクセスするタイミング

UI から Git フォルダーを作成すると、Azure Databricksワークスペースが対象の場合、Git CLI アクセスが自動的に有効になります。 ワークスペースが対象ではない場合は、代わりに Azure Databricks によって標準の Git フォルダーが作成されます。それでも、Git フォルダー UI から Git 操作を実行できます。

UI から作成した Git フォルダーは、次のすべてが当てはまる場合に Git CLI アクセスを取得します。

  • Git CLI プレビューは、ワークスペースで有効になっています。 ワークスペース管理者は 、[プレビュー ] ページからこれを制御します。 Azure Databricks プレビューの管理を参照してください。
  • サーバーレス コンピューティングは、ワークスペースで使用できます。 「サーバーレス コンピューティングに接続する」を参照してください。
  • Azure Databricksは、サーバーレス コンピューティングから Git プロバイダーにアクセスできます。 Azure Databricksは、リポジトリを複製する前に接続を検証します。 Git プロバイダーでプライベート ネットワーク接続が必要な場合は、「 ネットワーク接続の構成」を参照してください。
  • パブリック プレビュー中、リポジトリは 10,000 個のファイルに制限されます。 この制限を超えるリポジトリは、代わりに標準の Git フォルダーとして複製されます。

Web ターミナルから複製した Git フォルダーには、常に Git CLI アクセス権があります。

Git CLI アクセス権を持つ Git フォルダーを作成する

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

  • UI を使用すると、ワークスペースが対象である場合、Azure Databricks によって Git CLI アクセスが可能な Git フォルダーが自動的に作成されます。 Git フォルダーが Git CLI アクセスを取得するタイミングを参照してください。 ワークスペースが対象でない場合は、代わりに標準の Git フォルダー Azure Databricks作成します。
  • 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 許可リストは、Azure Databricks UI から実行する Git 操作に適用されますが、Git CLI で直接実行する Git コマンドには適用されません。
  • Git CLI アクセス権を持つ Git フォルダーは、List Repos API によって返されません。

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

  • ワークスペース UI で Git 操作が無効になっています。ワークスペースでサーバーレス コンピューティングが有効になっていません。 引き続き Web ターミナルから Git コマンドを実行できます。 サーバーレス コンピューティングを有効にするには、「 サーバーレス コンピューティングへの接続」を参照してください。
  • ターミナルから資格情報の選択が求められます。Git CLI 操作では、格納されているワークスペース の Git 資格情報が 自動的に使用されます。 Azure Databricksリモート URL から Git プロバイダーを推論し、そのプロバイダーの既定の資格情報を使用します。 Azure Databricks使用する 1 つの資格情報を識別できない場合は、資格情報を選択するように求められます。 プロンプトを回避するには、 DB_GIT_CREDENTIAL_NAME 環境変数に使用する資格情報の名前を設定します。 Azure Databricksは、リポジトリに使用する資格情報を記憶し、再利用します。
  • Git 操作がアクセス許可エラーで失敗する: 親フォルダーに CAN MANAGE アクセス許可があり、ワークスペースの Git 資格情報が有効であることを確認します。 「 Git プロバイダーを Databricks に接続する」を参照してください

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

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

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

    ノートブック上の Git ダイアログ ボタン。

  • Azure Databricks Git フォルダー ブラウザーで、リポジトリ名の横にある [Git ] をクリックします。

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

Databricks ワークスペースで Git 操作を実行するために使われるダイアログ。

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

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

ブランチ操作の [Git フォルダー] ダイアログのメニュー。

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

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

  1. Git ダイアログを開きます。
  2. [Create Branch] \(ブランチの作成\) をクリックします。
  3. 新しいブランチの名前を入力し、ベース ブランチを選択します。
  4. Create をクリックしてください。

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

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

別のブランチをチェックアウトするには、Git ダイアログのブランチ ドロップダウンを使用します。

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

コミットされていない変更が新しいブランチのコードと競合しない場合は、現在のブランチのコミットされていない変更が引き継がれ、新しいブランチでコミットされていない変更として表示されます。 コミットされていない変更を引き継ぐつもりがない場合は、ブランチ スイッチの前後の変更を破棄します。

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

重要

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

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

変更をコミットしてプッシュする

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

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

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

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

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

ロールとして動作している際の Git フォルダ内の作成者

RBAC では、ロールを引き受け、そのロールのスコープ内のデータにアクセスします。 そのデータを読み取るコードを作成するには、そのデータ アクセスが有効になるようにロールを引き受け、変更をコミットします。 独自のユーザー ID またはロールとしてコミットできます。 この選択によって、Git プロバイダーがコミットをどのように帰属させるかが決まり、その一方で、ワークフローに必要なセットアップの量とのトレードオフも生じます。 どちらも ロールの Git 資格情報に依存します。

Approach に関連付けられたコミット トレードオフ
ユーザー ID でコミットする あなた、個別に。 その他のセットアップ: 両方の ID でアクセスできるように Git フォルダーを共有し、コミットするユーザー ID に切り替えます。 読み取り専用ロールの資格情報で動作します。
そのロールでコミットする 役割。 より簡単: ロールとして機能し続け、フォルダーを共有しません。 コミットはロールの Git ID を持ち、ロールの Git 資格情報は書き込みアクセス権を持つ必要があり、ロールを引き受けるすべてのユーザーによって共有されます。

ユーザー ID でコミットする

この方法では、個人の Git 認証情報を使ってコミットするため、Git プロバイダーによってコミットがあなたのものとして記録されます。 このロールは、そのロールがアクセスできるデータに対して書き込みを行うためだけに引き受け、コミットを行う際には元のユーザー ID に戻します。 ロールとして機能しながら作成するが、ユーザー ID としてコミットする場合は、両方の ID で Git フォルダーに到達できる必要があります。 これは、フォルダーの所有者と共有する方向が異なる 2 つの方法のいずれかで設定します。

オプション 1: ホーム フォルダーに複製し、ロールと共有する

  1. ユーザー ID (ロールを想定しない) として、リポジトリをホーム フォルダー (/Workspace/Users/<your-username>/...) の Git フォルダーに複製します。 リポジトリのクローンを参照してください。 クローンでは、個人用の Git 資格情報が使用され、フォルダーの所有者はあなたになります。 ロールには、このオプション用の独自の Git 資格情報は必要ありません。
  2. そのロールとしてフォルダー内で作業できるように、ロールにフォルダーへのアクセス権(Can Run、またはロールがファイルを変更する必要がある場合は Can Edit)を付与します。
  3. ロールを想定し、フォルダーに変更を加えます。 ロールのデータアクセスは有効になっています。
  4. ユーザー ID に戻り、 コミットしてプッシュします。 コミットでは、個人の git_usernamegit_emailが使用されます。

ユーザー ID からロールにフォルダーを共有するため、 ワークスペース資産共有コントロール はこのオプションに影響しません。 これらのコントロールは、ロールのみがアセットを外部に共有できないように制限します。

オプション 2: ロールのホーム フォルダーに複製し、ユーザー ID と共有する

  1. ロールを想定 し、リポジトリをロールのホーム フォルダー内の Git フォルダーに複製します。 複製ではロールの Git 資格情報が使用されます。この資格情報には、少なくとも読み取りアクセス権が必要です。
  2. ロールとして機能しているときに、ユーザー ID にフォルダーへのアクセス権を付与します (編集可能)。
  3. そのロールを付与された状態で変更を加えます。 ロールのデータアクセスは有効になっています。
  4. ユーザー ID に戻ります。 ユーザー アクセス権を付与したため、フォルダーにアクセスできるため、個人の資格情報を 使用してコミットしてプッシュ できます。 コミットでは、個人の git_usernamegit_emailが使用されます。

ロールはフォルダーをユーザー ID の外部に共有するため、ロールが ワークスペース資産共有コントロール 拒否リストにある場合、このオプションは機能しません。 これらのロールにはオプション 1 を使用します。

ロールとしてコミットする

このアプローチでは、そのロールを付与された状態で、クローン、作成、コミットをすべて行います。 これは最も簡単なワークフローです。フォルダーを共有したり、コミットする ID を切り替えたりすることはありません。 ワークスペース UI は 1 回の操作でコミットとプッシュを行うため、そのロールの Git 認証情報には書き込み権限が必要です。

  1. 役割を担ってください
  2. リポジトリを Git フォルダーに複製します。 ロールとして機能しているため、複製ではロールの Git 資格情報が使用されます。
  3. 変更を加え、 コミットしてプッシュします。 コミットでは、ロールの git_usernamegit_emailが使用されます。

このアプローチを選択する前に、次の影響を検討してください。

  • 割り当てはロール レベルで行われます。 Git プロバイダーのコミットには、個々の作成者ではなく、ロールの Git ID が表示されます。 Azure Databricks の監査ログには、ワークスペース UI を通じて行われたコミットについて、identity_metadata.run_as(ロール)と identity_metadata.run_by(ユーザー)の両方が記録されます。 これは、Web ターミナルで Git CLI から実行される生の Git コミットには適用されません。Azure Databricksは個々のユーザーに属性を設定しません。
  • ロールの Git 資格情報は共有され、書き込みが有効になります。 そのロールを引き受けるすべての人が、プッシュに同じ認証情報を使用するため、漏えいした、または悪用されたトークンがあれば、プッシュしたり、ブランチを削除したり、そのロールの名義でコミットを作成したりできます。 このため、Azure Databricks では、読み取り専用のグループ Git 資格情報と、ユーザー ID を使用したコミット方式を推奨しています。 書き込みが有効な資格情報は、これらのトレードオフを受け入れた場合にのみ使用します。 トークンのアクセス許可を参照してください。 資格情報のスコープを、そのロールに必要なリポジトリのみに限定します。

変更をプルする

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

重要

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

Git フォルダーでの共同作業

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

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

Git フォルダーの構成をコラボレーターと共有するには:

  1. [共有] をクリックします。
  2. [ コピー] リンクをクリックして Git フォルダーを作成します
  3. コラボレーターに URL を送信します。
  4. コラボレーターが URL を開くと、Git フォルダー構成が事前に設定されたダイアログが表示されます。
  5. [ Git フォルダーの作成 ] をクリックして、リポジトリを現在の作業フォルダーの下にある独自のワークスペースに複製します。

ブランチをマージする

Azure Databricks Git フォルダーのマージ関数では、 git merge を使用して、あるブランチから別のブランチにコミット履歴を結合します。 Git 初心者の場合、Databricks では強制的なプッシュを必要とせず、コミット履歴を書き換えないので、リベースの代わりにマージを使用することをお勧めします。

1 つのブランチを別のブランチにマージするには、 Kebab メニュー アイコン をクリックします。kebab メニューをクリックし、[ マージ] を選択します。

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

マージの競合を解決する

マージの競合は、プル、リベース、マージ操作中など、異なるソースのファイルの同じ行に対する変更を Git が自動的に調整できない場合に発生します。

マージの競合を解決するには、競合するファイルと解決オプションを表示する Git フォルダー UI を使用します。

  • ファイルを手動で編集して、保持する変更を選択します。
  • 1 つのバージョンを完全に受け入れるには、[ 現在のすべての変更を保持 する] または [すべての受信変更 を受け取る] を選択します。
  • 操作を中止し、競合する変更を破棄して再試行します。

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

競合を手動で解決する

手動の競合解決を使用すると、受け入れる競合する行を決定できます。 ファイルの内容を直接編集して、競合を解決します。

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

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

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

ブランチをリベースする

Azure Databricks Git フォルダーのリベース関数では、 git rebase を使用して、ターゲット ブランチの上にコミットを再適用し、線形履歴を作成することで、あるブランチからの変更を別のブランチに統合します。

別のブランチでブランチをリベースするには、 Kebab メニュー アイコン をクリックします。kebab メニューをクリックし、[Rebase]\( リベース\) を選択してから、ターゲット ブランチを選択します。

  • リベース後、Git は git commitgit push --force を実行してリモート リポジトリを更新します。
  • リベースによってコミット履歴が書き換えられるため、同じリポジトリで作業しているコラボレーターのバージョン管理の問題が発生する可能性があります。

ブランチをリセットする

Git フォルダー UI から Git リセットを実行します。 この操作は、git reset --hardと組み合わせたgit push --forceと同じです。

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

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

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

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

重要

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

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

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

  2. から [Kebab menu icon.リセット] を選択します。kebab メニュー。

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

  3. リセットするブランチを選択し、[ Git リセットの実行] をクリックします。

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

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

新しいリポジトリを複製するときにスパース チェックアウト モードを有効にします。 スパース チェックアウト モードは、有効にした後で無効にすることはできません。

  1. [ Git フォルダーの作成 ] ダイアログで、 スパース チェックアウト モードを有効にします。

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

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

円錐パターンのしくみ

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

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

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

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

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

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

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

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

リポジトリを作成した後、 設定>Advanced>Cone パターンからスパース チェックアウト コーン パターンを編集します。

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

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

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

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

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

スパース チェックアウトを使用して変更を行う

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

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

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

  • スパース チェックアウトは、4 GB を超える Azure DevOps リポジトリでは機能しません。
  • スパース チェックアウトを有効にして作成されたリポジトリのスパース チェックアウトを無効にすることはできません。

Git フォルダーをプログラムで管理する

API を使用して Git フォルダーを管理するには、 Repos API リファレンスを参照してください

Git フォルダーを削除する

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

  1. Git フォルダーを右クリックし、[ ごみ箱に移動] を選択します。
  2. [確認] をクリック してごみ箱に移動します

次のステップ