本文章說明 Git 的基本概念和整合 Git 與 Microsoft Fabric 工作區的程序。
權限
- 組織的系統管理員必須 啟用 Git 整合。
- 如果工作區和 Azure 存放庫位於兩個不同的區域，租用戶系統管理員必須啟用跨地理位置匯出。 此限制不適用於 GitHub。
- 您在工作區和 Git 中擁有的許可權，如下一節所列，決定您可以採取的動作。
Git 常用操作所需的權限
下列清單顯示了根據它們在 Git 存放庫中的權限，不同的工作區角色可以執行的動作：
- 系統管理員：只能在工作區上執行任何作業，僅限其 Git 角色所限制。
- 成員/參與者：連線到工作區後，成員/參與者可以根據其 Git 角色提交和更新變更。 如需與工作區連線相關的動作 (例如，連線、中斷連線或切換分支)，請向管理員尋求協助。
- 查看器：無法執行任何動作。 觀察者在工作區中無法看見任何與 Git 相關的資訊。
常用操作所需的 Fabric 權限
工作區角色
下表描述了在 Fabric 工作區中執行各種常見作業所需的權限：
| 操作 | 工作區角色 |
|---|---|
| 將工作區連線至 Git 存放庫 | 管理員 |
| 同步工作區與 Git 存放庫 | 管理員 |
| 中斷工作區與 Git 存放庫的連線 | 管理員 |
| 在工作區切換分支（或任何連線設定的變更） | 管理員 |
| 檢視 Git 連線的詳細資料 | 管理員、成員、參與者 |
| 參閱工作區「Git 狀態」 | 管理員、成員、參與者 |
| 從 Git 中更新 | 下列所有角色： 工作區中的參與者 (具備所有項目的寫入權限) 項目的擁有者 (如果租用戶設定阻止非擁有者更新) 在需要的情況下建構外部依賴 |
| 將工作區變更提交到 Git | 下列所有角色： 工作區中的參與者 (具備所有項目的寫入權限) 項目的擁有者 (如果租用戶設定阻止非擁有者更新) 在需要的情況下建構外部依賴 |
| 從 Fabric 內部建立新的 Git 分支 | 管理員 |
| 切換到其他工作區 | 管理員、成員、參與者 |
Git 角色
下表描述了執行各種常見作業所需的 Git 權限：
| 操作 | Git 許可權 |
|---|---|
| 將工作區連線至 Git 存放庫 | 閱讀 = 允許 |
| 同步工作區與 Git 存放庫 | 閱讀 = 允許 |
| 中斷工作區與 Git 存放庫的連線 | 無需任何權限 |
| 在工作區切換分支（或任何連線設定的變更） | 讀取 = 允許 (在目標存放庫/目錄/分支中) |
| 檢視 Git 連線的詳細資料 | 可讀或無內容 |
| 參閱工作區「Git 狀態」 | 閱讀 = 允許 |
| 從 Git 中更新 | 閱讀 = 允許 |
| 將工作區變更提交到 Git | 閱讀 = 允許 參與 = 允許 分支策略應允許直接提交 |
| 從 Fabric 內部建立新的 Git 分支 | 角色：寫 建立分支 = 允許 |
| 切換到其他工作區 | 閱讀 = 允許 建立分支 = 允許 |
連線和同步
僅工作區管理員可以將工作區連線到 Git Repos，但一旦連線，具有權限的任何人均可以在工作區中工作。 如果您不是管理員，請向管理員尋求連線方面的協助。
當您 將工作區連線至 Git 時，Fabric 會在兩個位置之間同步處理，使其具有相同的內容。 在此初始同步期間，如果工作區和 Git 分支二者中任意一個位置是空的，而另一個有內容，則會將內容從非空位置拷貝到空位置。 如果工作區和 Git 分支均有內容，則必須決定同步方向。
- 如果將工作區提交到 Git 分支，所有受支援的工作區內容都會匯出到 Git，並會覆蓋目前的 Git 內容。
- 如果以 Git 內容更新工作區，則該工作區的內容會被覆寫，導致工作區內容遺失。 由於 Git 分支一律可以還原至上一個階段，而工作區則無法還原，因此如果選擇此選項，系統會要求您確認。
如果未選取要同步的內容，則無法繼續運作。
在工作區同步處理完成之前，您無法繼續工作的螢幕截圖通知。
資料夾
連線並同步處理時，工作區結構會鏡像在 Git 存放庫中，包括資料夾結構。 資料夾中的工作區項目會匯出至 Git 存放庫中具有相同名稱的資料夾。 相反地，Git 資料夾中的項目會匯入工作區中具有相同名稱的資料夾。
備註
由於會保留資料夾結構，如果您的工作區有資料夾，且連線的 Git 資料夾尚未有子資料夾，則會被視為不同。 您在原始碼控制面板中會看到 未提交的變更 狀態，並且在更新工作區之前需要將變更提交到 Git 儲存庫。 如果您先更新，Git 資料夾結構 會覆寫工作區 資料夾結構。 如需詳細資訊，請參閱 安全地處理資料夾變更。
- 空白資料夾不會複製到 Git。 當您建立或移動項目至資料夾時，資料夾會在 Git 中建立。
- Git 中的空白資料夾會自動刪除。
- 即使所有專案都移至不同的資料夾，工作區中的空白資料夾也不會自動刪除。
- 資料夾結構會保留最多10個層級。
安全地處理資料夾變更
如果您的工作區有資料夾，且連線的 Git 資料夾還沒有子資料夾，則會被視為不同，因為資料夾結構不同。 當您將具有資料夾的工作區連線至 Git 時，您會在原始檔控制面板中取得 未認可的變更 狀態，而且您必須在更新工作區之前認可 Git 的變更。
如果您無法直接變更已連線的分支，這可能是由於分支政策或許可權的限制，我們建議您使用簽出分支選項：
- 簽出新的分支：使用簽出分支功能來建立具備 Fabric 工作區更新狀態的分支。
- 提交資料夾變更：然後可以將任何工作區資料夾變更提交到這個新的分支。
- 合併變更：使用您的一般提取要求 （PR） 和合併程式，將這些更新整合回原始分支。
連線到共用工作區
如果您嘗試連線到已 連線到 Git 的工作區，您可能會收到下列訊息：
前往 [原始檔控制] 面板右側的 [帳戶] 索引標籤，選擇一個帳戶，然後連線到該帳戶。
![[帳戶] 索引標籤的螢幕快照，其中包含用戶連線到 GitHub 帳戶。](media/git-integration-process/connect.png)
git 狀態
連線之後，工作區會顯示 [Git 狀態] 資料行，指出工作區中每個項目相對於遠端分支中項目的同步狀態。
每個項目都有下列其中一個狀態：
-
已同步 (在工作區和 Git 分支中為同一個項目) -
衝突 (該項目在工作區和 Git 分支中均已被更改) -
不受支援的項目 -
工作空間中未提交的變更 -
需要從 Git 更新 -
項目在這兩個地方都是相同的，但需要更新至最新的提交
同步資訊
只要已連線，下列資訊就會出現在螢幕底部：
- 已連線的分支
- 上次同步時間
- 工作區所同步的最後一次提交的連結
原始碼控制窗格
螢幕頂端為 [原始檔控制] 圖示。 其顯示工作區和 Git 分支中有差異的項目的數目。 對工作區或 Git 分支進行更改時，此數目也會更新。 當工作區與 Git 分支同步時，原始檔控制圖示會顯示 0。
選取 [原始檔控制] 圖示以開啟 [原始檔控制] 面板。
原始檔控制窗格側邊有三個索引標籤：
提交和更新
對工作區或 Git 分支進行更改時，原始檔控制圖示會顯示有差異的項目的數目。 選取 [原始檔控制] 圖示以開啟 [原始檔控制] 面板。
提交與更新 面板有兩個區段。
[變更] 顯示工作區中已變更且需要認可至 Git 的項目數目。
更新 顯示在 Git 分支中被修改的項目數，以及需要更新至工作區的項目。
在每個區段中，已更改的項目會使用一個指出其狀態的圖示列出：
-
新增 -
已修改 -
已刪除 -
衝突
-
相同變更
面板上方的 [重新整理]
按鈕用以更新變更清單。
提交
- 工作區中已更改的項目列在 [變更] 區段中。 當有多個已更改的項目時，你可以選擇哪些項目提交至 Git 分支。
- 如果對 Git 分支進行了更新，則會停用提交，直到您更新工作區為止。
更新
- 與提交和復原不同，更新命令會更新整個分支，並同步到最新的提交。 無法選取特定項目進行更新。
- 如果在工作區和 相同專案的 Git 分支中進行變更，則會停用更新，直到 衝突解決為止。
深入瞭解如何 提交 和 更新。 深入瞭解更新程式，以及如何 解決衝突。
分支
您可以使用 [原始檔控制] 面板的 [分支] 索引標籤管理分支並執行分支相關動作。 它有兩個主要區段：
您可以在最新分支上採取的動作：
- 分支至另一個工作區 （貢獻者及以上）：建立新的工作區，或根據當前工作區的最後提交切換至現有的工作區。 然後，它會連線到目標工作區和分支。
- 檢出新分支（必須是工作區管理員）：根據工作區中上次同步的提交紀錄建立新的分支，並變更目前工作區中的 Git 連線。 其不會更改工作區內容。
- 切換分支 （必須是工作區管理員）：將工作區與另一個新的或現有的分支同步，並使用所選分支的內容覆蓋工作區中的所有項目。
相關分支。
[c0]分支[/c0]頁籤中還有相關的工作區清單，您可以選擇並切換。 相關工作區與最新分支具有相同的連線屬性，例如相同的組織、專案、存放庫和 Git 資料夾。
這項功能可讓您瀏覽至連線到與目前工作內容相關的其他分支的工作區，而不需要在 Fabric 工作區清單中尋找它們。
若要開啟相關的工作區，請選取清單中的專案。
如需詳細資訊，請參閱 分支出限制。
帳戶詳細資料
[帳戶詳細資料] 索引標籤顯示使用者所連線的 GitHub 帳戶的詳細資料。 它有兩個區段。 頂端區段顯示 Git 提供者和帳戶名稱。 底部區段顯示工作區所連線的存放庫和分支。 目前，此索引標籤僅適用於已連線至 GitHub 的工作區。
GitHub 帳戶詳細資料包括：
Git 帳戶詳細資料
- 提供者
- 帳戶名稱
Git 存放庫
分支
![[原始檔] 控制面板中 [帳戶] 索引標籤的螢幕快照，其中顯示 Git 詳細數據和存放庫和分支名稱。](media/git-integration-process/github-account-details.png)
考量與限制
Git 整合的一般限制
- Fabric 中的 驗證方法 至少必須和 Git 的驗證方法一樣強。 例如，如果 Git 需要多重要素驗證，Fabric 也需要多重要素驗證。
- 目前不支援連線至 Analysis Services 的 Power BI 資料集。
- 如果您在某個工件中使用工作區身分識別並將其提交至 Git，則只能在連線至相同身分識別的工作區中更新它（返回到一個網狀架構的工作區）。 請小心，因為這也會影響分支輸出之類的功能。
- 不支援子模組。
- 主權雲端不被支援。
- 如果你的工作區有數百個項目，可以考慮將其拆分成較小的工件集合。 每組應該放置在獨立的工作空間中，並鏈接到不同的 Git 分支，或連接到在不同資料夾中組織的單一分支。
- 如果已啟用 啟用IP條件式存取原則驗證 ，則不支援 Azure DevOps。
- 如果工作區和 Git 存放庫位於兩個不同的地理區域，租用戶系統管理員必須啟用 跨地理位置匯出。
- 如果您的組織已設定 條件式存取，請確定 Power BI服務 已設定相同的 條件 ，以便驗證如預期般運作。
- 以下是適用的提交大小限制：
- 使用 Azure DevOps 連接器搭配 Service Principal，使用 25 MB。
- 125 MB，使用預設的單一登入（SSO）Microsoft Entra ID 帳號及 Azure DevOps 連接器，並使用 User Principal。
GitHub Enterprise 限制
不支援某些 GitHub Enterprise 版本和設定。 例如：
- 具有數據駐留的 GitHub Enterprise Cloud (ghe.com)
- 即使該伺服器公開可存取，GitHub Enterprise Server 使用自定義網域依然不受支援。
- 架設於私人網路上的 Github Enterprise Server
- IP 允許清單
Azure DevOps 到 GitHub Enterprise 遷移考量
如果您的團隊使用 Fabric Git 整合，並正在評估從 Azure DevOps 遷移到 GitHub Enterprise，建議執行驗證測試以確保 Git 整合功能不受影響。 Fabric Git 整合依賴底層的 Git 提供者 API，這些 API 在 Azure DevOps 與 GitHub Enterprise 之間的能力與限制有所不同，如上所述。
工作區限制
- 只有工作區管理員可以管理 Git 存放庫 的連線，例如連線、中斷連線或新增分支。
連線之後，具有 許可權 的任何人都可以在工作區中工作。 - 已安裝範本應用程式的工作區無法連線到 Git。
- MyWorkspace 無法連線到 Git 提供者。
分支限制與資料夾限制
- 分支名稱長度上限為 244 個字元。
- 檔案名稱的完整路徑長度上限為 250 個字元。 名稱太長通常會失敗。
- 檔案大小上限為 25 MB。
- 資料夾結構最多可達到10個層級深。
- 不建議在使用 Git 整合部署報表/數據集後，從服務下載為 .pbix ，因為結果不可靠。 我們建議使用PowerBI Desktop將報表/數據集下載為 .pbix。
- 如果項目的顯示名稱具有下列任何特性，Git 資料夾會重新命名為邏輯識別碼 （Guid） 並輸入：
- 字元數超過 256 個
- 結尾是 。 或是空格
- 包含任何禁止字元，這些字元已在目錄名稱限制中有所描述
- 當您將具有資料夾的工作區連接到 Git 時，如果資料夾結構有所不同，則必須將變更提交至 Git 存放庫。
目錄名稱限制
線上至 Git 存放庫的目錄名稱具有下列命名限制：
- 目錄名稱不能以空格或 Tab 開頭或結尾。
- 目錄名稱不能包含下列任何字元：“/：<>\*|
專案資料夾（包含專案檔案的資料夾）不能包含下列任何字元： “：<>\*？|。 如果您將資料夾重新命名為包含其中一個字元，則 Git 無法連線或同步處理工作區，並會發生錯誤。
分支限制
- 拓展需要許可權數據表中列出的許可權。
- 必須有可用的容量才能執行此動作。
- 所有 工作區 和 分支命名限制 都會在分支至新的工作區時套用。
- 新的工作區中僅提供 Git 支援的專案 。
- 相關的分支清單僅顯示您有權檢視的分支和工作區。
- 必須啟用 Git 整合。
- 當建立分支時，會建立新的分支，而且不會複製原始分支中的設定。 調整任何設定或定義，以確保新符合貴組織的原則。
- 擴展到現有工作空間時：
- 目標工作區必須支援 Git 連線。
- 用戶必須是目標工作區的管理員。
- 目標工作區必須具有容量。
- 工作區不能有範本應用程式。
- 請注意，當您分支至工作區時，未儲存至 Git 的任何項目都會遺失。 建議您在分支之前 提交 任何想要保留的項目。
同步和提交限制
- 一次只能在一個方向上同步。 您無法同時提交和更新。
- 不支援敏感度標籤，並且可能會停用匯出具有敏感度標籤的項目。 若要提交應具有但實際上沒有敏感度標籤的專案，請向系統管理員尋求協助。
- 適用於 有限的項目。 資料夾中不受支援的項目會略過。
- 不允許複製名稱。 即使 Power BI 允許重複名稱，更新、認可或復原動作也會失敗。
- 不支援 B2B。
- 衝突解決 是在 Git 中部分完成的。
- 在 認可 Git 程式期間，Fabric 服務會刪除不屬於專案定義之 專案資料夾內的 檔案。 不會刪除不在項目資料夾中的非相關檔案。
- 提交變更之後，您可能會注意到項目有一些您未做出的非預期改變。 這些變更在語意上無關緊要，且可能存在多個原因。 例如：
- 手動變更項目定義檔案。 這些變更有效，但可能不同於透過編輯器完成的變更。 例如，如果您在 Git 中重新命名語意模型數據行，並將這項變更匯入至工作區，下次提交對語意模型的更改時，bim 檔案將會註冊為已修改，並將修改的數據行推送至陣列的最後
columns。 這是因為產生 bim 檔案的 AS 引擎會將重新命名的數據行推送至陣列結尾。 這項變更不會影響項目的運作方式。 - 認可使用 CRLF 換行符的檔案。 服務使用 LF （換行符） 進行換行。 如果您在 Git 存放庫中有 CRLF 換行符的項目檔案，從服務提交時這些檔案將變更為 LF。 例如，如果您在桌面中開啟報表，請使用CRLF儲存項目檔 （.pbip） 並將其上傳至 Git。
- 手動變更項目定義檔案。 這些變更有效，但可能不同於透過編輯器完成的變更。 例如，如果您在 Git 中重新命名語意模型數據行，並將這項變更匯入至工作區，下次提交對語意模型的更改時，bim 檔案將會註冊為已修改，並將修改的數據行推送至陣列的最後
- 使用增強式重新整理 API 重新整理語意模型，會在每次重新整理之後產生 Git 差異。