適用於： ✅ Microsoft Fabric 中的倉庫
本文說明利用 Fabric 內建的 Git 整合來開發與部署 Fabric Data Warehouse 的優勢。
Important
這項功能目前處於預覽階段。
透過在 Fabric 中使用 Git 整合，團隊可以將現代的原始碼控制實務應用於倉庫開發。 開發者可以在分支中隔離變更、透過提交追蹤結構描述演進、透過提取要求進行協作，並在 Git 存放庫與 Fabric 工作區之間同步更新。
一般案例包括：
- 在分支與工作空間中安全地開發結構變更
- Git 中的倉庫物件版本管理
- 跨多個分支與工作空間的協作
- 促進分支間經過驗證的變更
- 保持工作區項目（倉庫及其他）與 Git 真實來源對齊
為了在倉庫開發生命週期中維持一致性、可追溯性與可靠性，你需要了解這些工作流程。
當你把 Fabric Data Warehouse 工作區連接到 Git，你就是把倉庫定義提交成資料庫專案。 此專案成為原始碼控制中倉庫結構的權威表示，並作為持續開發活動的基礎。 在原始碼控制檔案總管中，結構模式會以獨立 .sql 檔案的形式出現。
透過使用 Fabric Git 整合與Fabric Data Warehouse，您可以：
- 用 Git 整合開發Fabric Data Warehouse。
- 使用部署管線部署Fabric Data Warehouse。
- 部署及持續部署可使用 Fabric 入口網站、Git、您自己的 IDE 或本機開發環境、Fabric 部署管線，或外部持續整合/持續部署 (CI/CD) 系統，包括 Azure DevOps Services 或 GitHub 中的管線。
比較
在此同步過程中，Fabric 採用基於 DacFx 的增量結構部署來套用變更。 此方法僅將相關的結構差異套用於倉庫，而非更新整個倉庫定義。
增量擷取有助於減少原始碼控制中不必要的變動，維持各分支之間更清晰的結構描述差異，並支援高效率的分支與合併流程。 由於擷取過程具備結構感知，也使工作區狀態與 Git 追蹤定義之間能可靠地比較與驗證。
標準化倉庫架構的擷取與儲存方式，有助於提升開發環境間的一致性。 結構定義在各分支間保持穩定，差異更準確反映開發的有意變更，且原始碼控制成為部署、協作與生命週期管理的可靠基準。
在 Git 整合的工作流程中，檔案 XMLA.json 本身會被排除在外。 Fabric 會將這個檔案排除在提交和更新之外，避免預設語意model元資料被無意間儲存在 Git 裡。 從 Git 同步工作區時，系統會忽略 XMLA.json，這有助於避免衝突、非預期的覆寫，以及在切換分支或從 Git 更新時產生的雜訊。
原始檔控制的限制
SQL 安全功能如權限，匯出與遷移需以腳本為基礎。 請考慮在 SQL 資料庫專案中使用部署後腳本。 你可以在專案中使用 Visual Studio Code 中的 SQL Database Projects 擴充功能來設定部署後的腳本。
目前開發工作流程中不支援倉庫與 SQL 分析端點之間的跨項目相依。 因此，依賴這些項目間協調變更的情境可能無法穩定運作。
透過 Git 直接加入資料庫專案的部署前或部署後腳本，以及額外的發佈設定，不會被保留在開發工作流程中。 你可能需要在 Fabric 工作區之外分別管理這些設定。
倉庫層級的選擇性提交目前尚不支援。 變更是在倉庫項目層級提交，而非更細緻的物件層級。
目前尚無 SQL 分析端點的版本控制支援。 當解決方案同時涵蓋倉庫與 SQL 分析端點時，這種限制可能會限制端到端的生命週期管理。
Git 整合的限制
- 當兩個或多個倉儲項目相互參考時，會形成循環相依關係。 系統會在執行分支建立或 Git 到工作空間的同步作業時偵測到這個循環參考，導致這些作業失敗。 避免項目間的循環依賴。
- 目前，請不要建立資料流 Gen2，其輸出目的地是倉庫。 在
DataflowsStagingWarehouse倉庫中新出現了一個名為DataflowsStagingWarehouse的檔案，並阻止從 Git 提交和更新。 - 跨項目相依、項目排序，以及 SQL 分析端點與倉庫之間的同步缺口，會影響開發與持續整合期間「分支到新工作區或現有工作區」以及「切換到不同分支」的工作流程。
- 如果某個物件使用三段式命名（
database.schema.object）來參考同一個倉庫中的另一個物件，從 Git 提交或更新變更時可能會失敗。 欲了解更多資訊及解決方法，請參閱 「使用三部分名稱參考倉庫自身物件」。 - 如果你變更了已定義
IDENTITY的欄，從 Git 提交或更新時可能會失敗，直到為該資料表啟用IDENTITY_INSERT為止。 - 如果存放庫包含將
Microsoft.Build.SqlSDK 版本固定為較舊版本的.sqlproj檔案，透過 Git 提交或更新時可能會失敗，因為舊版 SDK 無法辨識較新的 warehouse 語法，例如IDENTITY資料行和CLUSTER BY。 欲了解更多資訊及解決方法，請參閱 Git 倉庫中的過時 .sqlproj。 - 如果物件參考另一個倉庫中的兩個或以上資料表，且未為每個欄位進行別名限定，從 Git 提交或更新可能會失敗。 欲了解更多資訊及解決方法，請參閱 物件中不合格欄位，該物件會參考另一個倉庫中兩個或以上資料表。
- 如果你的腳本在另一個倉庫的同一個結構中引用兩個或以上不同的物件，且結構名稱大寫不一致，從 Git 提交或更新可能會失敗。 欲了解更多資訊及解決方法，請參閱 結構名稱的不一致大小寫。
- 在從 Git 提交或更新時，即使沒有真正的歧義，也可能出現候選清單中包含
::分隔符的歧義欄位錯誤。 欲了解更多資訊與解決方法，請參閱 帶有重複候選物件的模糊欄位錯誤。
不支援的場景
以下 CI/CD 工作流程在不同工作空間的倉庫具有不同排序時不受官方支援。 即使這些操作可能成功且無錯誤，也可能導致元資料錯誤。
在所有這些情境中，若發生排序規則不匹配，請使用 Fabric 工具箱 GitHub 倉庫中的 Python 腳本 scripts/dw-collation-error-update-tmsl/pbi_interactive.py 更新資料集（TMSL）的排序規則以匹配倉庫的排序規則。
| 情境 | Description | 風險 |
|---|---|---|
| 部署管道 | 透過流程階段（例如開發→測試→生產）推廣倉庫內容，且目標倉庫的整合方式與原始碼不同，是不被支援的。 | 部署可能成功，但資料集整合結果無法更新到與目標倉庫整合一致。 |
| 拓展到新工作區或現有工作區 | 使用 Git 整合從現有工作區分支到新建或現有工作區（倉庫有不同排序）是不支援的。 | 倉庫內容已同步，但排序的元資料未對齊。 |
| 在工作區切換分支 | 在 連接到 Git 的工作區中，切換到與不同排序的倉庫相關聯的分支不是支援的。 | 同步的內容可能會帶有不符合目前資料倉儲的排序假設。 |
| 透過分支合併工作區間的變更 | 在不同排序規則的倉庫之間的工作區合併 Git 分支是不支援的。 | 合併可能在 Git 層級成功，但結果的資料集整合不會反映目標倉庫的整合。 |