この記事では、Microsoft Fabricの Git 統合ツールで次の基本的なタスクについて説明します。
- Git リポジトリに接続する
- 変更をコミットする
- Git から更新する
- Git から切断する
開始する前に、 Git 統合の概要 を確認することをお勧めします。
前提条件
Git を Microsoft Fabric ワークスペースと統合するには、Fabric と Git の両方に次の前提条件を設定する必要があります。
Fabric の前提条件
Git 統合機能をaccessするには、Fabric 容量が必要です。 サポートされているすべての Fabric 項目を使用するには、Fabric 容量が必要です。 まだお持ちでない場合は、 無料試用版にサインアップしてください。 既に Power BI Premium 容量を持っているお客様は、その容量を使用できますが、特定の Power BI SKU では Power BI 項目のみがサポートされることに注意してください。
さらに、管理ポータルから次の テナント スイッチ を有効にする必要があります。
- ユーザーは Fabric アイテムを作成できます - Fabric アーティファクトを使用する場合に必要です
- ユーザーは、ワークスペース項目を自分の Git リポジトリと同期できます
- ワークスペースを作成する (新しいワークスペースに分岐する場合のみ)。
- ユーザーはワークスペースアイテムをGitHubリポジトリと同期できます: GitHubユーザーのみ
これらのスイッチは、 組織の設定に応じて、テナント管理者、容量管理者、またはワークスペース管理者が有効にすることができます。
Git の前提条件
Git 統合は現在、Azure DevOps と GitHub でサポートされています。 Fabric ワークスペースと Git 統合を使用するには、Azure DevOps または GitHubで次のものが必要です。
- Active Azure DevOps アカウント同じ Fabric ユーザーに登録されます (Azure DevOps 組織が Fabric テナントとは異なるテナントに存在する場合でもサポートされます)。 無料アカウントを作成します。
- 既存のリポジトリにAccessします。
ワークスペースをGitリポジトリに接続する
Git リポジトリに接続する
ワークスペースをリポジトリに接続できるのはワークスペース管理者だけですが、接続後は権限を持つすべてのユーザーがワークスペースで作業できるようになります。 管理者でない場合は、管理者に連絡して、接続の支援をしてもらってください。 ワークスペースを Azure または GitHub Repo に接続するには、次の手順に従います。
Fabric にサインインし、接続するワークスペースに移動します。
[ワークスペース設定] に移動します
上部に [ワークスペース設定] アイコンが表示されたワークスペースのスクリーンショット。
[Git 統合] を選択します。
Git プロバイダーを選択します。 現時点では、devOps と GitHub Azureがサポートされています。
DevOps Azure選択した場合は、Connect を選択して、Fabric にサインインした Microsoft Entra ユーザーに登録されたAzure Repos アカウントに自動的にサインインします。
別のアカウントを使用して Fabric から Azure に既にサインインしている場合は、一覧から自分のアカウントを選択し、Connect を選択します。
Fabric から初めてサインインする場合、または新しいアカウントを追加する場合は、[ アカウントの追加] を選択します。
初めて接続する場合は、ユーザーを承認する必要があります。 次の情報を指定します。
- 表示名 - ユーザーごとに一意である必要があります
-
Azure DevOps URL - Azure DevOps リポジトリの URL。 URL は、
https://dev.azure.com/{organization}/{project}/_git/{repository}またはhttps://{organization}.visualstudio.com/{project}/_git/{repo}の形式である必要があります。 - 認証 - OAuth2 または サービス プリンシパルを使用して認証できます。 詳細については、「Azure DevOps - Git とサービス プリンシパルの統合」を参照してください>
サインインした後、Connect を選択して、Fabric がアカウントをaccessできるようにします
ワークスペースに接続する
ワークスペースが既に Azure DevOps/GitHub に接続されている場合は、共有ワークスペースへの接続の手順に従います。
ドロップダウン メニューから、接続するブランチに関する以下の詳細情報を指定します。
- Organization
- Project
- Git リポジトリ。
- ブランチ (このドロップダウン メニューを使用して既存のブランチを選択する、または [+ 新しいブランチ] を選択して新しいブランチを作成します。一度に接続できるブランチは 1 つだけです)。
- フォルダー (既存のフォルダーの名前を入力するか、名前を入力して新しいフォルダーを作成します。フォルダー名を空白のままにすると、ルート フォルダーにコンテンツが作成されます。一度に接続できるフォルダーは 1 つだけです)。
[接続と同期] を選択します。
初期同期中に、ワークスペースまたは Git ブランチが空の場合、コンテンツは空ではない場所から空の場所にコピーされます。 ワークスペースと Git ブランチの両方にコンテンツがある場合、同期をどちらの方向に行うかを尋ねられます。 この初期同期の詳細については、「接続と同期」を参照してください。
接続すると、ワークスペースにソース管理に関する情報が表示され、ユーザーは接続されたブランチ、ブランチ内の各項目の状態、最後の同期時刻を表示できます。
ソース管理アイコンとその他の Git 情報のスクリーンショット。
ワークスペースと Git ブランチの同期を保つには、ワークスペースで行った変更をすべて Git ブランチにコミットし、誰かが Git ブランチに新しいコミットを作成するたびにワークスペースを更新します。
Git に変更をコミットする
Git フォルダーに正常に接続したら、通常どおりワークスペースを編集します。 保存した変更はワークスペースにのみ保存されます。 準備ができたら、変更を Git ブランチにコミットすることも、変更を元に戻して前の状態に戻すこともできます。
コミットの詳細については、こちらをご覧ください。
- Git にコミットする
- スタンドアロン ブランチへのコミット
- 保存された変更を元に戻す
変更を Git ブランチにコミットするには、次の手順に従います。
ワークスペースに移動します。
[ソース管理] アイコンを選びます。 このアイコンは、コミットされていない変更の数を示します。 コミットする変更が 2 つあることを示す、数字 2 が付いたソース管理アイコンのスクリーンショット。
[ソース管理] パネルの [変更] を選択します。 変更したすべての項目と、項目が新しい、変更、競合、同じ変更、または削除されたかどうかを示すアイコンが一覧表示。
コミットする項目を選択します。 すべての項目を選択するには、上部のボックスにチェックを入れます。
ボックスにコメントを追加します。 コメントを追加しない場合は、デフォルトのメッセージが自動的に追加されます。
「コミット」を選択します。
コミットする 2 つの変更が選択されたソース管理ウィンドウのスクリーンショット。
変更がコミットされると、コミットされた項目が一覧から削除され、ワークスペースは同期先の新しいコミットを指します。
コミットする変更がないことを示すソース管理ウィンドウのスクリーンショット。
コミットが正常に完了すると、選択した項目の状態が [未コミット] から [同期済み] に変わります。
Git からワークスペースを更新する
接続された Git ブランチに新しい変更をコミットすると、関連するワークスペースに通知が表示されます。 [ソース管理] パネルを使用して、最新の変更、統合、または元に戻す作業をワークスペースに取り込み、ライブ項目を更新します。 フォルダーへの変更も更新されます。 更新に関する詳細をご覧ください。
ワークスペースを更新するには、次の手順に従います。
- ワークスペースに移動します。
- [ソース管理] アイコンを選びます。
- 「更新」をソースのコントロールパネルで選択します。 前回の更新以降にブランチで変更されたすべての項目のリストが表示されます。
- [すべて更新] を選択します。
- 確認ダイアログで、[ 更新] を選択します。
確認ダイアログのスクリーンショット。
正常に更新されると、項目の一覧が削除され、ワークスペースは同期先の新しいワークスペースを指します。
ワークスペースが正常に更新されたことを示すソース管理ウィンドウのスクリーンショット。
更新が正常に完了すると、項目の状態が [同期済み] に変わります。
Git からワークスペースを切断する
ワークスペース管理者だけが、ワークスペースを Git リポジトリから切断できます。 管理者ではない場合は、切断について管理者に問い合わせてください。 管理者がリポジトリを切断する場合は、次の手順に従います。
- [ワークスペース設定] に移動します
- [Git 統合] を選択します
- [ワークスペースの切断] を選択します
- もう一度 [切断] を選択して確認します。
権限
ワークスペースで実行できるアクションは、ワークスペースと Git リポジトリの両方で持っている権限によって異なります。 アクセス許可の詳細については、「アクセス許可」を参照してください。
考慮事項と制限事項
一般的な Git 統合の制限事項
- Fabric の認証方法は、少なくとも Git の認証方法と同程度に強力である必要があります。 たとえば、Git で多要素認証が必要な場合、Fabric でも多要素認証が必要になります。
- 現時点では、Analysis Services に接続されている Power BI データセットはサポートされていません。
- 1 つの成果物でワークスペース ID を使用して Git にコミットした場合、同じ ID に接続されているワークスペースでのみ更新 (ファブリック ワークスペースに戻す) ことができます。 ブランチ アウトなどの機能にも影響するため、注意してください。
- サブモジュールはサポートされていません。
- ソブリン クラウドはサポートされていません。
- ワークスペースに何百もの項目が含まれている場合は、小さなartifactsセットに分割することを検討してください。 各セットは、個別のワークスペースに配置し、異なる Git ブランチにリンクするか、異なるフォルダーに編成された単一のブランチに接続する必要があります。
- Azure DevOps は、有効な IP 条件付きAccess ポリシー検証 が有効になっている場合はサポートされません。
- ワークスペースと Git リポジトリが 2 つの異なる地理的リージョンにある場合、テナント管理者は 複数の地理的なエクスポートを有効にする必要があります。
- 組織で conditional access を構成している場合は、認証が想定どおりに機能するように、Power BI Serviceに同じconditions setがあることを確認します。
- 次のコミット サイズ制限が適用されます。
- Azure DevOps コネクタとサービス プリンシパルを使用して 25 MB。
- 既定のシングル サインオン (SSO) Microsoft Entra ID アカウントと Azure DevOps コネクターをユーザー プリンシパルと共に使用して 125 MB。
GitHub Enterprise の制限事項
一部のGitHub Enterprise のバージョンと設定はサポートされていません。 次に例を示します。
- custom domainを持つエンタープライズ サーバー GitHubは、インスタンスがパブリックにアクセスできる場合でもサポートされていません
- プライベート ネットワークでホストされているエンタープライズ サーバーのGitHub
- IP 許可リスト
Azure DevOps から GitHub Enterprise への移行に関する考慮事項
チームで Fabric Git Integration を使用し、Azure DevOps から GitHub Enterprise への移行を評価する場合は、検証テストを実行して Git 統合機能が影響を受けないようにすることをお勧めします。 Fabric Git Integration は、基になる Git プロバイダー API に依存します。これは、前述のように、Azure DevOps と GitHub Enterprise の機能と制限が異なります。
ワークスペースの制限事項
- 接続、切断、ブランチの追加など、Git Repo への接続を管理できるのは、ワークスペース管理者だけです。
接続すると、アクセス許可を持つすべてのユーザーがワークスペースで作業できるようになります。 - テンプレート アプリがインストールされているワークスペースを Git に接続することはできません。
- MyWorkspace は Git プロバイダーに接続できません。
- ワークスペースには、最大 1,000 個のアイテムを含めることができます。 Git ブランチに 1,000 を超える項目が含まれている場合、ワークスペースへのコンテンツの同期は失敗します。 この制限を回避するには、artifactsをより小さなセットに分割することを検討してください。 各セットは、個別のワークスペースに配置し、異なる Git ブランチにリンクするか、単一のブランチ内の異なるフォルダーに編成する必要があります。 詳細については、 ワークスペース項目の制限に従ってください。
ブランチとフォルダーの制限事項
- ブランチ名の最大長は 244 文字です。
- ファイル名の完全パスの最大長は 250 文字です。 これより長い名前は失敗します。
- 最大ファイル サイズは 25 MB です。
- フォルダー構造は、最大 10 レベルの深さまで維持されます。
- Git 統合を使用してレポート/データセットをデプロイした後、サービスから .pbix としてレポート/データセットをダウンロードすることはお勧めしません。結果は信頼できないためです。 Power BI Desktop を使用して、レポート/データセットを .pbix としてダウンロードすることをお勧めします。
- 項目の表示名にこれらの特性のいずれかが含まれている場合、Git フォルダーの名前は論理 ID (Guid) に変更され、次のように入力されます。
- 256文字を超えている
- で終わります。 またはスペース
- ディレクトリ名の制限事項に記載されている、禁止された文字が含まれる
- フォルダーを含むワークスペースを Git に接続する場合、その フォルダー構造 が異なる場合は、Git リポジトリに変更をコミットする必要があります。
ディレクトリ名の制限事項
Git リポジトリに接続するディレクトリの名前には、次の名前付け制限があります。
- ディレクトリ名の先頭または末尾をスペースまたはタブにすることはできません。
- ディレクトリ名には、次の文字を含めることはできません: ":?
アイテム フォルダー (アイテム ファイルを含むフォルダー) には、次の文字を含めることはできません: ":?。 フォルダーの名前をこれらの文字のいずれかを含む名前に変更すると、Git はワークスペースに接続または同期できなくなり、エラーが発生します。
分岐の制限事項
- ブランチ アウトには、アクセス許可テーブル に記載されているアクセス許可が必要です。
- このアクションには使用可能な容量が必要です。
- ワークスペース と ブランチの名前付けの制限事項 はすべて新しいワークスペースにブランチ アウトするときに適用されます。
- 新しいワークスペースでは、Git でサポートされている項目 のみを使用できます。
- 関連するブランチの一覧には、表示するアクセス許可を持つブランチとワークスペースのみが表示されます。
- Git 統合 を有効にする必要があります。
- 分岐すると、新しいブランチが作成され、元のブランチの設定はコピーされません。 すべての設定または定義を調整して、新しい設定が組織のポリシーを満たしていることを確認します。
- 既存のワークスペースに分岐する場合:
- ターゲット ワークスペースは Git 接続をサポートしている必要があります。
- ユーザーは、ターゲット ワークスペースの管理者である必要があります。
- ターゲット ワークスペースには容量が必要です。
- ワークスペースにテンプレート アプリを含めることはできません。
- ワークスペースに分岐すると、Git に保存されていない項目が失われる可能性があることに注意してください。 分岐する前に、保持する必要がある項目をコミットすることをお勧めします。
同期とコミットの制限事項
- 同期できる方向は一度に 1 つだけです。 同時にコミットと更新をすることはできません。
- 秘密度ラベルはサポートされていないため、秘密度ラベルを持つアイテムのエクスポートは無効化される可能性があります。 秘密度ラベルのない秘密度ラベルを持つ項目をコミットするには、 管理者にヘルプを依頼してください 。
- 制限付きアイテムで動作します。 フォルダー内のサポートされていない項目は無視されます。
- 名前の複製は許可されません。 Power BI で名前の重複が許可されている場合でも、更新、コミット、または元に戻すアクションは失敗します。
- B2B はサポートされていません。
- 競合の解決 は、Git で部分的に行われます。
- Git へのコミット プロセス中に、Fabric サービスは、アイテム定義の一部ではないアイテム フォルダー内のファイルを削除します。 アイテム フォルダーにない無関係なファイルは削除されません。
- 変更をコミットした後、自分が加えなかった予期しない変更が項目に加えられる場合があります。 これらの変更は意味的には重要ではなく、いくつかの理由で発生する可能性があります。 例:
- 項目定義ファイルを手動で変更します。 これらの変更は有効ですが、エディターを使用して行った場合とは異なる可能性があります。 たとえば、Git でセマンティック モデル列の名前を変更し、この変更をワークスペースにインポートすると、次回セマンティック モデルに変更をコミットするときに、bim ファイルが変更済みとして登録され、変更された列が 配列の後ろにプッシュされます。 これは、bim ファイルを生成する AS エンジンが名前変更された列を配列の最後にプッシュするためです。 この変更は項目の動作には影響しません。
- CRLF 改行を使用するファイルをコミットする。 このサービスでは LF (ライン フィード) 改行を使用しています。 CRLF 改行を含む項目ファイルが Git リポジトリにある場合、サービスからコミットすると、これらのファイルは LF に変更されます。 たとえば、デスクトップでレポートを開いた場合は、project ファイル (.pbip) を保存し、CRLF を使用して Git にアップロードします。
- 拡張更新 API を使ってセマンティック モデルを更新すると、更新のたびに Git diff が行われます。
関連するコンテンツ
- Git 統合プロセスを理解する
- Git ブランチを管理する
- Git 統合のベスト プラクティス