使用版本控制和部署

本页面假定您的项目已设置为使用版本控制。如果您看到的是配置 Git 按钮，而不是本页介绍的选项，那么您需要先为项目设置 Git。

Looker 使用 Git 记录更改并管理文件版本。每个 LookML 项目都对应于一个 Git 代码库，每个开发者分支都与一个 Git 分支相关联。

Looker 可配置为与许多 Git 提供商（例如 GitHub、GitLab 和 Bitbucket）搭配使用。如需了解如何为 Looker 项目设置 Git，请参阅设置和测试 Git 连接文档页面。

使用 Git 分支

Git 的一个主要优势是，Looker 开发者可以在分支（文件代码库的隔离版本）中工作。您可以在不影响其他用户的情况下进行开发和测试。作为 Looker 中的开发者，只要处于开发模式，您就会使用 Git 分支。

Git 的另一项主要功能是，它可以让您轻松与其他开发者协作。您可以创建一个分支并视需要进行更改，然后其他开发者可以切换到该分支以查看或更改该分支。如果其他开发者已向分支提交了更改，Looker 会显示拉取远程更改按钮。您应先将已提交的更改拉取到分支，然后再进行其他更改。

除了主分支、当前分支或开发者的个人分支之外，您还可以删除分支。

个人分支

当您首次进入开发模式时，Looker 会自动创建您的个人 Git 分支。您的个人分支以 dev- 开头，并包含您的姓名。

您的个人分支是专属于您的，因此无法删除。您的个人分支对所有其他开发者而言都是只读的。如果您与其他开发者协作处理某个项目，则可能需要创建一个新分支，这样其他人就可以切换到该分支并贡献更改。

注意 ：您无法更改其他开发者的个人分支。要在他人的个人分支继续工作，请从其分支开始创建一个新分支。

创建新的 Git 分支

如果您正在进行简单的修复，而不与其他开发者协作，则您的个人分支通常是一个不错的选择。您可以使用个人分支进行快速更新，然后提交更改并将其推送到生产环境。

不过，除了个人分支之外，您可能还需要创建新的 Git 分支。在以下情况下，可以创建新的 Git 分支：

• 您与其他开发者合作。由于您的个人分支对其他开发者而言是只读的，因此如果您想与他人协作，则应创建一个新的 Git 分支，以便其他开发者可以写入该分支。与他人协作时，请务必在每次恢复工作时拉取更改。这样，您就可以在继续工作之前了解所有开发者的最新动态。
• 您同时处理多组功能。有时，您可能正在进行重大项目，但希望解决一些小问题或快速修复。在这种情况下，您可以将更改提交到当前分支，然后创建或切换到其他分支，以处理另一组功能。您可以在新分支中进行修复，然后将该分支的更改部署到生产环境中，然后再继续原始分支中的工作。

在创建新分支之前，请执行以下操作：

• 如果当前分支存在合并冲突，您必须先解决冲突，然后才能创建新分支。
• 如果当前分支上有任何未提交的更改，您必须先提交当前分支上的更改，然后才能创建新分支。
• 如果要从现有的开发分支（而不是生产分支）开始创建分支，请先切换到该开发分支以获取最新版本的开发分支，然后拉取远程更改以同步该分支的本地版本。

如需创建新的 Git 分支，请执行以下操作：

1. 确认您已开启开发模式。

2. 在 Develop 菜单中前往项目文件。

   

3. 选择左侧图标菜单中的 Git 图标，以打开 Git 操作面板。

4. 选择查看分支下拉菜单。

5. 选择 New Branch。

   

6. 在 New Branch 窗口中，输入分支的名称。请注意，Git 分支名称存在限制；如需了解命名要求，请参阅本页面中的 Git 分支命名规则。

7. 选择 Create From（从中创建）下拉菜单，然后选择一个现有分支作为新分支的起点。

8. 选择创建以创建您的分支。

或者，您也可以通过项目设置的分支管理标签页创建 Git 分支。

Git 分支命名规则

Looker 使用 Git 指定的分支命名惯例要求。

Git 分支名称不得：

• 包含空格字符
• 包含双重句点：..
• 包含反斜杠：\
• 包含序列：@{
• 包含问号：?
• 包含左方括号：[
• 包含 ASCII 控制字符：~、\^ 或 :
• 以英文句号开头：.
• 以前缀 dev- 开头（预留给 Looker 开发者的个人分支）
• 以正斜杠结尾：/
• 以扩展名 .lock 结尾

此外，分支名称只能包含星号 (*)，前提是星号代表整个路径组件（例如 foo/* 或 bar/*/baz），在这种情况下，星号会被解读为通配符，而不是实际分支名称的一部分。

切换到其他 Git 分支

如果当前分支存在合并冲突，您必须先解决冲突，然后才能切换到其他分支。

此外，如果您当前分支上有未提交的更改，则必须先提交更改，然后才能切换到现有分支。

如需切换到其他 Git 分支，请按以下步骤操作：

1. 在项目中，选择左侧图标菜单中的 Git 图标，前往 Git 操作面板。
2. 在 Git Actions 面板中，选择当前 Git 分支名称右侧的 Git 分支下拉菜单。
3. 在菜单中选择要切换到的分支，或在搜索框中输入分支名称。分支名称搜索不区分大小写。例如，您可以搜索“DEV”，然后查看名称中包含“dev”“DEV”“Dev”等字样的所有分支。

管理 Git 分支

项目设置的 Branch Management（分支管理）标签页会显示一个表格，其中列出了 Looker 项目的所有 Git 分支。如需打开分支管理标签页，请先从左侧图标菜单中选择设置图标，进入项目设置。接下来，选择 Branch Management 标签页。

在分支管理标签页中，您可以执行以下操作：

1. 选择新建分支按钮以创建新分支。如需了解详情，请参阅本页中的创建新的 Git 分支部分。
2. 在搜索栏中搜索分支名称。
3. 选择刷新按钮以刷新表格。
4. 通过选择列名称对表进行排序。

该表格包含以下信息：

• 名称：Git 分支的名称。Looker 开发者的个人分支以 dev- 开头，并包含开发者的名字和姓氏。
• 状态：分支的本地版本与远程版本之间的区别。例如，状态为 3 commits behind 表示分支的本地版本比分支的远程版本落后了 3 个提交。由于 Looker 始终使用主实例的远程版本，因此分支管理标签页不会显示主实例分支的本地版本的状态。主分支始终会被视为最新。
• 上次更新时间：Looker 开发者向分支提交代码后经过的时间。
• 操作：用于删除分支的按钮，或分支不符合删除条件的原因。

删除 Git 分支

通过分支管理标签页，您可以删除表中具有删除按钮的分支。您无法删除以下分支：

• master 分支
• 您当前的分支
• Looker 开发者的个人分支

在表格中，这些分支没有删除按钮。相反，该表的操作列会显示无法删除分支的原因。

分支一经删除，便无法恢复。删除分支后，Looker 会同时移除分支的本地版本和远程版本。

不过，如果分支是由其他 Looker 开发者创建的，或者其他开发者已检出该分支，那么这些开发者仍会保留其本地版本的分支。如果 Looker 开发者提交分支的本地版本并将其推送到生产环境，您将再次看到分支的远程版本。如果您确实想要恢复分支，这会非常方便。否则，当您删除某个分支时，所有其他 Looker 开发者都应删除该分支，以确保有人将其推送到远程仓库时不会意外重新显示该分支。

如需从项目中删除一个或多个 Git 分支，请先从左侧图标菜单中选择设置图标，前往项目设置。然后，选择分店管理标签页。在 Branch Management 标签页中，您可以通过以下两种方式删除分支：

1. 如需删除多个分支，请先选中相应分支的复选框，然后选择删除所选分支。
2. 选择分支名称旁边的 Delete 可删除单个分支。

在 Looker 中执行 Git 命令

Looker 有一个内置界面，可与您的 Git 服务集成。Looker 会在 LookML IDE 的右上角显示 Git 按钮。

Git 按钮会显示不同的选项，具体取决于您在更改和部署到生产环境的过程中所处的位置。一般来说，按钮上显示的选项是您下一步行动的最佳指南。

如果您的开发者分支与生产分支同步，Git 按钮会显示 Up to Date 消息且不可选择。

将项目配置为使用 Git 后，您可以选择 Git 操作按钮以打开 Git 操作面板。

Git Actions 面板上可用的命令取决于您在更改和部署到 生产环境 的过程中所处的阶段。

将更改推送到生产环境

使用默认的 Looker Git 集成时，Looker 会提示开发者完成以下 Git 工作流：

• 对开发者的当前开发分支提交更改（如果您的项目设置为在部署之前需要测试，则还需要运行数据测试）
• 将开发分支合并到生产分支（默认情况下称为 master）
• 将生产分支部署到将呈现给 Looker 最终用户的 Looker 生产环境

这意味着，通过默认 Git 集成，所有开发者都会将其更改合并到一个名为 master 的分支中，master 分支上的最新提交内容将用于 Looker 的生产环境。

对于高级 Git 实现，您可以自定义此工作流：

• 您可以让开发者为您的 Git 生产分支提交拉取请求，而不是允许开发者通过 Looker IDE 合并更改。如需了解详情，请参阅配置项目版本控制设置文档页面。
• 您可以使用 Git 生产分支名称字段指定 Looker 应将 Git 代码库中的哪个分支用作将 Looker 开发者的分支合并到的目标分支。如需了解详情，请参阅配置项目版本控制设置文档页面。
• 您可以使用高级部署模式指定要部署到 Looker 生产环境的其他提交 SHA 或标记名称，而不是使用生产分支上的最新提交。（如果您要从其他分支部署提交内容，可以使用高级部署模式 webhook 或 API 端点。）如需了解详情，请参阅高级部署模式文档页面。

如果您看到 Configure Git 按钮（而不是本部分中所述的选项），则需要先为项目设置 Git。

查看未提交的更改

当您处于开发模式且有未提交的更改时，LookML IDE 会显示多个指示器，如 Looker IDE 概览文档页面中的标记添加、更改和删除操作部分所述。

您可以从 Git 操作面板中选择查看未提交的更改选项，以获取所有文件的差异摘要。

在对项目的未提交更改窗口中，Looker 会显示项目所有文件中所有未提交的已保存更改的摘要。对于每项更改，Looker 都会显示以下内容：

• 被替换文件的名称和添加文件的名称。
  • 替换文件的名称（以 --- 表示）和添加的文件的名称（以 +++ 表示）。在很多情况下，这可能会显示同一文件的不同版本，其中修订版本由 --- a/ 和 +++ b/ 标识。
  • 已删除的文件显示为替换空文件 (+++ /dev/null)。
  • 添加的文件显示为替换 null 文件 (--- /dev/null)。
• 更改开始的行号。
  例如，-101,4 +101,4 表示在文件的第 101 行，移除了 4 行并添加了 4 行。如果删除的文件包含 20 行，则会显示 -1,20 +0,0，表示文件的第一行中移除了 20 行，并将其替换为 0 行。
• 更新后的文本：
  • 已删除的行会以红色显示。
  • 添加的行会以绿色显示。

如需显示单个文件的差异摘要，请从该文件的菜单中选择查看更改选项。

提交更改

对 LookML 项目进行任何更改并保存后，IDE 可能会要求您验证 LookML。在这种情况下，Git 按钮会显示 Validate LookML 文本。

是否必须执行此操作取决于项目的代码质量设置。如需详细了解内容验证器，请参阅验证 LookML 文档页面。

如果自您上次更新本地分支以来，其他开发者对生产分支进行了更改，Looker 会要求您从生产分支中拉取这些更新。在这种情况下，Git 按钮会显示从生产环境拉取文本。

如果您的项目启用了高级部署模式，Git 按钮将改为显示 Pull from Primary Branch（从主分支拉取）文字。

保存更改（并修正任何 LookML 警告或错误，如果需要）并从生产环境中拉取（如果需要）后，Git 按钮会显示文本提交更改和推送。

如果需要，您可以先查看未提交的更改，然后再提交。

准备好提交更改后，请使用 Git 按钮将这些更改提交到当前分支。Looker 会显示提交对话框，其中列出了已添加、更改或删除的文件。

输入简要说明更改的消息，并清除不想同步的文件旁边的复选框。然后，选择提交以提交更改。

检查是否有未构建的 PDT

如果您更改了项目中的任何 PDT，则最好在部署到生产环境时构建所有 PDT，以便这些表可以立即用作生产环境版本。如需查看项目中的 PDT 状态，请选择 Project Health（项目健康状况）图标以打开 Project Health（项目健康状况）面板，然后选择 Validate PDT Status（验证 PDT 状态）按钮。

如需详细了解如何在 LookML 项目中检查未构建的 PDT，以及如何在开发模式下使用派生表，请参阅 Looker 中的派生表文档页面。

运行数据测试

您的项目可能包含一个或多个 test 参数，用于定义数据测试以验证 LookML 模型的逻辑。如需了解如何在项目中设置数据测试，请参阅 test 参数文档页面。

注意：默认情况下，新的 LookML 项目需要数据测试通过。如果您的项目包含一个或多个 test 参数，则必须先通过数据测试，然后才能将项目部署到生产环境。

如果您的项目包含数据测试，并且您处于开发模式，则可以通过多种方式启动项目的数据测试：

1. 如果您的项目设置配置为要求数据测试通过，然后才能将文件部署到生产环境，那么在您对项目提交更改后，IDE 会显示运行测试按钮，以便运行项目的所有测试，无论是哪个文件定义了测试。您必须先通过数据测试，然后才能将更改部署到生产环境中。
2. 在项目健康状况面板中，选择运行数据测试按钮。无论哪个文件定义了测试，Looker 都会运行您项目中的所有数据测试。
3. 从该文件的菜单中选择运行 LookML 测试 (Run LookML Tests) 选项。Looker 将仅运行当前文件中定义的测试。

运行数据测试后，Project Health 面板将显示进度和结果。

• 当测试查询中的每一行的断言为 true 时，数据测试就会通过。如需详细了解如何设置测试断言和查询，请参阅 test 参数文档页面。
• 如果数据测试失败，Project Health 面板会提供有关测试失败原因的信息，例如测试是否在模型逻辑中发现了错误，或者测试本身是否无效。
• 在数据测试结果中，您可以选择数据测试的名称，直接前往该数据测试的 LookML；也可以选择 Explore Query 按钮，打开一个包含数据测试中定义的查询的“探索”页面。

部署到生产环境

向分支提交更改后，Looker IDE 会提示您将更改合并到主分支。您在 IDE 中看到的提示类型取决于项目的配置：

• 如果您的项目配置为高级部署模式，IDE 会提示您将更改合并到主分支。合并提交内容后，拥有 deploy 权限的 Looker 开发者可以使用 Looker IDE 部署管理器或者使用 webhook 或 API 端点，将提交内容部署到生产环境中。
• 如果您的项目使用拉取请求配置为 Git 集成，系统将提示您使用 Git 提供方的界面打开拉取请求。
• 否则，如果您使用默认的 Looker Git 集成，并且拥有 deploy 权限，Looker IDE 会提示您将更改合并到生产分支，并将更改部署到 Looker 实例的生产版本。

高级部署模式

通过默认的 Looker Git 集成，Looker 开发者会将更改提交到开发分支，然后将开发分支合并到生产分支。然后，当您部署到 Looker 环境时，Looker 会在生产分支上使用最新的提交内容。（如需了解默认 Git 工作流和高级 Git 实现的其他选项，请参阅本页面的将您的更改发布到生产环境部分）。

如果您不希望始终为 Looker 环境使用生产分支上的最新提交，则拥有 deploy 权限的开发者可以使用高级部署模式指定要为 Looker 环境使用的确切提交。这在多环境开发者工作流中非常有用，在工作流中，每个环境都指向不同版本的代码库。它还可让一位或多位开发者或管理员更好地控制部署到生产环境的更改。

启用高级部署模式后，Looker IDE 不会提示开发者将其更改部署到生产环境。相反，IDE 会提示开发者将更改合并到生产分支。然后，只能通过以下方式部署更改：

• 使用 Looker IDE 中的 Deployment Manager
• 触发 webhook

• 使用 API 端点

  注意 ：对于启用了高级部署模式的项目，如果项目从未部署到生产环境，则必须使用 Looker IDE 中的部署管理器进行初始部署到生产环境。对于使用高级部署模式的项目，您无法使用 API 或 webhook。在初次部署到生产环境后（即使最初部署时未使用高级部署模式），您可以使用 webhook 或 API 使用高级部署模式将后续更改部署到生产环境。

如需了解详情，请参阅高级部署模式文档页面。

查看更改的影响

将更改应用到组织后，您可以使用内容验证来确保未使任何信息中心或已保存的 Look 失效。您将有机会解决这些问题。

处理典型问题

在处理模型时，您可能需要执行以下操作：

• 放弃您的更改

  有时，您可能希望放弃数据建模更改。如果尚未保存，您只需刷新或离开该页面，然后接受警告提示即可。如果已保存更改，则可以还原未提交的更改，如还原未提交的更改部分中所述。

• 处理与其他开发者工作的合并冲突

  如果您有多个开发者在处理您的数据模型，Git 通常会处理这种情况。不过，Git 有时需要有人解决合并冲突。

某些更改（例如更改字段名称）可能会影响现有的信息中心和 Look。如前所述，在向组织提供更改后，您可以使用内容验证检查内容并解决所有问题。

还原未提交的更改

在处理个人开发分支时，如果您不想部署已保存的更改，可以还原它们。您可以还原项目中所有文件的所有未提交更改，也可以仅还原单个文件中的更改。

如需还原所有文件的未提交更改，请执行以下操作：

1. 在 Git 操作面板中，选择还原为...选项。
2. 选择还原选项：
   • 如需仅还原未提交的更改，请选择还原未提交的更改。您还可以选择查看更改链接，查看将还原的更改。
   • 如需还原所有更改，包括未提交和已提交的更改，请选择还原为正式版
3. 如要完成还原流程，请选择确认。

要还原对单个文件的内容执行的任何添加或删除操作，请从该文件的菜单中选择还原更改选项：

如果您重命名文件，实质上是删除原始文件，并用新名称创建一个新文件。由于此操作涉及多个文件，因此您无法使用还原文件选项撤消文件的重命名。如果要撤消文件的重命名，请使用 Git 操作面板中的还原为...选项。

此外，如果您删除了某个文件，则 IDE 文件浏览器中将不再显示该文件。如果要还原文件的删除操作，请使用 Git 操作面板中的还原为...选项。

解决合并冲突

通常，Git 可以自动将您的新更改与 LookML 文件的生产版本合并。当 Git 遇到冲突的更改且无法确定应保留哪些更改时，就会发生合并冲突。通常，当其他开发者在您上次拉取代码后进行了更改，而您也在同一区域进行了更改时，就会发生这种情况。如果您的代码存在合并冲突，在您提交更改并从生产环境拉取后，Looker 会显示合并冲突警告。

当 Looker 显示合并冲突警告时，我们建议您先解决合并冲突，然后再做出进一步更改。将合并冲突推送到生产环境会导致解析错误，这可能会阻止您探索数据。如果您是高级 Git 用户，并且想要继续推送更改，请选择不解析按钮。

在 LookML 文件本身中，存在冲突的行标记如下：

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker 会显示以下合并标记来指示合并冲突：

• <<<<<<<HEAD 标记了冲突行的开头。
• >>>>>>> branch 'master' 标记冲突行的结尾。
• ======= 用于分隔代码的每个版本，以便您进行比较。

在前面的示例中，your code 表示您提交的更改，production code 表示 Git 无法将更改自动合并到的代码。

如需解决合并冲突，请执行以下操作：

1. 找到存在合并冲突的文件。Looker 将这些文件标记为红色，您也可以在项目中搜索以查找合并标记，例如 <<<<或 HEAD 来查找项目中的所有冲突。您也可以在 Git 操作面板中显示的合并警告中选择文件链接，找到受影响的文件。
2. 在文件中，找到存在合并冲突的行，删除您不想保留的文本版本，并删除所有合并冲突标记。

3. 保存文件，并对标记有合并冲突的任何其他文件重复上述步骤。

   提示： 在您的项目中搜索每个合并标记，确认您已解决所有冲突并删除所有合并标记。请务必从 LookML 文件中移除所有合并标记实例。这些标记会导致解析错误，可能会阻止用户探索您的数据。

4. 解决所有合并冲突并从项目中删除所有合并标记后，提交更改并将其部署到生产环境。

现在，您已解决合并冲突并将解决方案推送至正式版，其他开发者可以从正式版中拉取，并照常工作。

Git 垃圾回收

Git 垃圾回收：清理不必要的文件并压缩文件修订版本，以优化 Git 代码库。当您更新或重新启动 Looker 实例时，Git 垃圾回收 (git gc) 会自动运行。为避免过于频繁地运行 git gc，Looker 会从上次 git gc 起等待 30 天，然后在下次重新启动时运行 git gc。

在极少数情况下，您可以在 git gc 运行时尝试将更改推送到远程或将分支推送到远程。如果 Looker 显示错误，请等待一两分钟，然后重新尝试推送您所做的更改。