本文介绍基本的 Git 概念以及将 Git 与 Microsoft Fabric 工作区集成的过程。
权限
- 组织的管理员必须 启用 Git 集成。
- 如果工作区和 Azure 存储库位于两个不同的区域,则租户管理员必须启用跨地理位置导出。 此限制不适用于 GitHub。
- 工作区和 Git 中拥有的权限,如后续部分中所列,决定了您可以执行的操作。
常用操作所需的 Git 权限
下表显示了根据 Git 存储库权限的不同工作区角色可以执行哪些操作:
- 管理员:可以在工作区上执行任何操作,仅受其 Git 角色的限制。
- 成员/参与者:连接到工作区后,成员/参与者可以提交和更新更改,具体取决于其 Git 角色。 对于与工作区连接相关的操作(例如,连接、断开连接或切换分支),请向管理员寻求帮助。
- 查看器:无法执行任何操作。 查看者在工作区中看不到任何 Git 相关信息。
常用操作所需的 Fabric 权限
工作区角色
下表描述了在 Fabric 工作区中执行各种常见操作所需的权限:
操作 | 工作区角色 |
---|---|
将工作区连接到 Git 存储库 | 管理员 |
将工作区与 Git 存储库同步 | 管理员 |
断开工作区与 Git 存储库的连接 | 管理员 |
在工作区中切换分支(或连接设置中的任何更改) | 管理员 |
查看 Git 连接详细信息 | 管理员、成员、参与者 |
查看工作区“Git 状态” | 管理员、成员、参与者 |
从 Git 更新 | 所有下述角色: 工作区中的参与者(对所有项拥有 WRITE 权限) 项目的所有者(如果租户开关阻止了非项目所有者的更新) 对外部依赖项的 BUILD 权限(如适用) |
将工作区更改提交到 Git | 所有下述角色: 工作区中的参与者(对所有项拥有 WRITE 权限) 项目的所有者(如果租户开关阻止了非项目所有者的更新) 对外部依赖项的 BUILD 权限(如适用) |
在 Fabric 中创建新的 Git 分支 | 管理员 |
切换到另一个工作区 | 管理员、成员、参与者 |
Git 角色
下表描述了执行各种常见操作所需的 Git 权限:
操作 | Git 权限 |
---|---|
将工作区连接到 Git 存储库 | 读取=允许 |
将工作区与 Git 存储库同步 | 读取=允许 |
断开工作区与 Git 存储库的连接 | 无需任何权限 |
在工作区中切换分支(或连接设置中的任何更改) | Read=Allow(在目标存储库/目录/分支中) |
查看 Git 连接详细信息 | 读取或无 |
查看工作区“Git 状态” | 读取=允许 |
从 Git 更新 | 读取=允许 |
将工作区更改提交到 Git | 读取=允许 贡献=允许 分支策略应允许直接提交 |
在 Fabric 中创建新的 Git 分支 | 角色=写 创建分支=允许 |
切换到另一个工作区 | 读取=允许 创建分支=允许 |
连接和同步
只有工作区管理员可以将工作区连接到 Git 存储库,但连接后,具有权限的任何人都可以在工作区中工作。 如果你不是管理员,请向管理员请求有关连接的帮助。
将工作区连接到 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 的工作区,可能会收到以下消息:
转到“源代码管理”面板右侧的“帐户”选项卡,选择一个帐户,并连接到该帐户。
Git 状态
连接后,工作区会显示一个 Git 状态 列,指示工作区中每个项相对于远程分支中的项的同步状态。
每个项都具有以下状态之一:
-
已同步(项目在工作区和 Git 分支中是相同的)
-
冲突(同时在工作区和 Git 分支中更改了项)
-
不受支持的项
-
工作区中未提交的更改
-
需要从 Git 更新
-
项在两个位置相同,但需要更新到上次提交
同步信息
只要你已连接,屏幕底部就会显示以下信息:
- 连接的分支
- 上次同步的时间
- 工作区同步到的最后一个提交的链接
“源代码管理”窗格
屏幕顶部是“源代码管理”图标。 它显示了工作区和 Git 分支中不同项目的数量。 对工作区或 Git 分支进行更改时,将更新该数字。 当工作区与 Git 分支同步时,源代码管理图标将显示 0。
选择“源代码管理”图标以打开“源代码管理”面板。
“源代码管理”面板在一侧有三个选项卡:
提交并更新
对工作区或 Git 分支进行更改时,源代码管理图标会显示不同的项数。 选择“源代码管理”图标以打开“源代码管理”面板。
“提交和更新”面板有两个部分。
“更改”显示工作区中已更改且需要提交到 Git 的项目数。
“更新”显示 Git 分支中已修改且需要更新到工作区的项目数。
在每个部分中,都会列出已更改的项,并带有一个指示状态的图标:
-
新
-
已修改
-
已删除
-
冲突
面板顶部的“刷新”按钮可更新更改和更新列表。
提交
- 已更改的工作区中的项目列在“更改”部分。 当有多个已更改的条目时,你可以选择将哪些条目提交到 Git 分支。
- 如果对 Git 分支进行了更新,提交操作将被禁止,直到你更新你的工作区。
更新
- 与 提交 和 撤消不同, Update 命令始终更新整个分支并同步到最新的提交。 无法选择特定的项进行更新。
- 如果在同 一项的工作区和 Git 分支中进行了更改,则在 解决冲突之前,将禁用更新。
详细了解如何 提交 和 更新。 详细了解更新过程以及如何 解决冲突。
分支
使用“源代码管理”面板的“分支”选项卡,可以管理分支并执行分支相关操作。 它有两个主要部分:
可以在当前分支上执行的操作:
- 扩展到另一个工作区(参与者及更高级别):创建新工作区,或根据当前工作区的最后一次提交情况切换到现有工作区。 然后,它连接到目标工作区和分支。
- 签出新分支(必须是工作区管理员):基于工作区中上次同步的提交创建新分支,并更改当前工作区中的 Git 连接。 它不会更改工作区内容。
- 切换分支 (必须是工作区管理员):将工作区与其他新分支或现有分支同步,并使用所选分支的内容覆盖工作区中的所有项。
相关分支。
“分支”选项卡还包含一系列相关工作区,你可以选择并切换到这些工作区。 相关工作区与当前分支具有相同的连接属性,例如同一组织、项目、存储库和 git 文件夹。
此功能允许导航到连接到与当前工作上下文相关的其他分支的工作区,而无需在 Fabric 工作区列表中查找它们。
若要打开相关工作区,请选择列表中的项。
有关详细信息,请参阅 分支限制。
帐户详细信息
“帐户详细信息”选项卡会显示用户所连接的 GitHub 帐户的详细信息。 共包含两个部分。 顶部部分显示 Git 提供程序和帐户名称。 底部部分展示了工作区所连接的存储库和分支。 目前,此选项卡仅适用于连接到 GitHub 的工作区。
GitHub 帐户详细信息包括:
Git 帐户详细信息
- 提供商
- 帐户名
Git 存储库
分支
注意事项和限制
常规 Git 集成限制
- Fabric 中的 身份验证方法 必须至少与 Git 的身份验证方法一样强。 例如,如果 Git 需要多重身份验证,则 Fabric 也需要多重身份验证。
- 目前不支持连接到 Analysis Services 的 Power BI 数据集。
- 如果在一个项目中使用工作区标识并将其提交到 Git,则只能在连接到同一标识的工作区中更新它(返回到构造工作区)。 请小心,因为这也会影响分支操作等功能。
- 不支持子模块。
- 目前不支持主权云。
- Azure DevOps 帐户必须注册到使用 Fabric 工作区的同一用户。
- 如果启用 “启用 IP 条件访问策略验证 ”,则不支持 Azure DevOps。
- 如果工作区和 Git 存储库位于两个不同的地理区域,则租户管理员必须启用跨地区导出。
- 如果组织配置 了条件访问,请确保 Power BI 服务 具有与身份验证相同的 条件 ,以便按预期运行。
- 提交的大小限制为 125 MB。
GitHub Enterprise 限制
不支持某些 GitHub Enterprise 版本和设置。 例如:
- 具有数据驻留的 GitHub Enterprise Cloud (ghe.com)
- 不支持具有自定义域的 GitHub Enterprise Server,即使该实例可公开访问
- 托管在专用网络上的 Github Enterprise Server
- IP 允许列表
工作区限制
- 只有工作区管理员可以管理与 Git 存储库 的连接,例如连接、断开连接或添加分支。
连接后,具有 权限 的任何人都可以在工作区中工作。 - 安装了模板应用的工作区无法连接到 Git。
- MyWorkspace 无法连接到 Git 提供程序。
分支和文件夹限制
- 分支名称的最大长度为 244 个字符。
- 文件名的完整路径的最大长度为 250 个字符。 过长的名称会失败。
- 文件大小上限为 25 MB。
- 文件夹结构最多可达 10 个级别的深度。
- 不建议在使用 Git 集成后,将已部署的报表/数据集从服务中下载为 .pbix 文件,因为结果可能不可靠。 建议使用 PowerBI Desktop 将报表/数据集下载为 .pbix。
- 如果项的显示名称具有以下任一特征,则 Git 文件夹将重命名为逻辑 ID (Guid) 和类型:
- 超过 256 个字符
- 以 . 或空格结尾
- 包含目录名称限制中所述的任何禁止字符
- 当您将具有文件夹的工作区连接到 Git 时,如果 文件夹结构 不同,您需要将更改提交到 Git 仓库。
目录名称限制
连接到 Git 存储库的目录的名称存在以下命名限制:
- 目录名称不能以空格或制表符开头或结尾。
- 目录名称不能包含以下任何字符:“/:<>\*|
项目文件夹(包含项目文件的文件夹)不能包含以下任何字符:“:<>\*?|。 如果将文件夹重命名为包含前述任何字符的名称,Git 将无法连接工作区或与之同步,并发生错误。
分支限制
- 扩展延伸需要权限表中列出的权限。
- 必须有可用容量可供此操作使用。
- 所有 工作区 和 分支命名限制 在分支到新工作区时适用。
- 新工作区中仅提供 Git 支持的项 。
- 相关分支列表仅显示你有权查看的分支和工作区。
- 必须启用 Git 集成。
- 分出分支时,会创建一个新分支,并且不会复制原始分支中的设置。 调整任何设置或定义,以确保新策略符合组织的策略。
- 当切换到现有工作区时:
- 目标工作区必须支持 Git 连接。
- 用户必须是目标工作区的管理员。
- 目标工作区必须具有容量。
- 工作区不能有模板应用。
- 请注意,当你分支到工作区时,未保存到 Git 的任何项都可能会丢失。 建议在分支之前提交要保留的任何项。
同步和提交限制
- 一次只能向一个方向同步。 无法同时提交和更新。
- 不支持敏感度标签,可能会禁用导出具有敏感度标签的项。 要提交未附带敏感度标签的项目时,请咨询管理员以获得帮助。
- 适用于受限项。 将忽略文件夹中不受支持的项。
- 不允许出现重复名称。 即使 Power BI 允许出现重复名称,更新、提交或撤消操作也会失败。
- 不支持 B2B。
- 冲突解决 在 Git 中部分完成。
- 在提交到 Git 的过程中,Fabric 服务将删除项文件夹中不属于项定义的文件。 不会删除不在项目文件夹中的不相关文件。
- 提交更改后,你可能会注意到项目中出现了一些非你修改的意外更改。 这些更改在语义上是微不足道的,可能出于多种原因而发生。 例如:
- 手动更改项定义文件。 这些更改是有效的,但可能与通过编辑器完成的更改不同。 例如,如果在 Git 中重命名语义模型列并将此更改导入工作区,则下次向语义模型提交更改时,bim 文件将注册为已更改,修改后的列将推送到
columns
数组的后面。 这是因为生成 bim 文件的 AS 引擎会将重命名的列推送到数组的末尾。 此更改不会影响项的操作方式。 - 提交使用 CRLF 换行符的文件。 该服务使用 LF(行摘要)换行符。 如果在 Git 存储库中有带 CRLF 换行符的项文件,则从服务提交时,这些文件将更改为 LF。 例如,如果在桌面中打开报表,请保存项目文件(.pbip),并使用 CRLF 将其上传到 Git。
- 手动更改项定义文件。 这些更改是有效的,但可能与通过编辑器完成的更改不同。 例如,如果在 Git 中重命名语义模型列并将此更改导入工作区,则下次向语义模型提交更改时,bim 文件将注册为已更改,修改后的列将推送到
- 使用 增强刷新 API 刷新语义模型会导致每次刷新后出现 Git 差异。