使用版本控制和部署

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

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

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

使用 Git 分支

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

Git 的另一个主要功能是它能够轻松地与它提供的其他开发者进行协作。您可以创建分支并视需要进行更改，然后其他开发者即可切换到该分支，以查看或更改该分支。如果其他开发者对此分支进行了更改，Looker 会显示拉取远程更改按钮。在执行其他更改之前，您应将这些更改提交到分支。

您也可以删除 master 分支、当前分支或开发者个人分支。

个人分支机构

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

您的个人分支专属于您，无法删除。您的个人分支对所有其他开发者来说都是只读的。如果您正就某个项目与其他开发者协作，则可能需要创建新分支，以便其他人也能切换到该分支并做出相应更改。

注意 ：您无法更改其他开发者的个人分支。若要在其他人的个人分支中构建工作，请基于其分支创建新分支。

创建新的 Git 分支

如果您开发的是简单的修复方案，且不与其他开发者协作，那么您的个人分支机构通常是一个不错的工作场所。您可以使用个人分支快速完成更新，然后提交更改并将其推送到生产环境中。

但是，除了个人分支之外，您可能还需要创建新的 Git 分支。新的 Git 分支适用于以下情况：

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

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

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

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

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

2. 在 Develop 菜单中导航到您的项目文件。

   

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

4. 选择 View Branches 下拉菜单。

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 Actions 面板。
2. 在 Git 操作面板中，选择当前 Git 分支名称右侧的“Git 分支”下拉菜单。
3. 选择要切换到的分支，方法是在菜单中选择相应分支，或在搜索框中输入分支名称。分支名称搜索不区分大小写。例如，您可以搜索“DEV”，然后查看名称包含“dev”、“DEV”、“Dev”等的所有分支。

管理 Git 分支

“项目设置”页面的分支管理标签页会显示一个表，其中包含 Looker 项目的所有 Git 分支。如需打开 Branch Management 标签页，请先从左侧图标菜单中选择 Settings 图标，前往 Project Settings 页面。接下来，选择 Branch Management 标签页。

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

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

表格包含以下信息：

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

删除 Git 分支

在 Branch Management 标签页中，您可以删除表中具有 Delete 按钮的分支。您无法删除以下分支：

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

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

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

不过，如果分支是由其他 Looker 开发者创建的，或者其他开发者已签出分支，那么这些开发者将继续使用其本地版本的分支。如果 Looker 开发者提交本地版本的分支并将其推送到生产环境中，您将再次看到分支的远程版本。如果您确实想恢复该分支，此方法会很方便。否则，当您删除分支时，所有其他 Looker 开发者都应删除相同的分支，以确保有人在将其推送到远程分支时不会再对其进行意外重新呈现。

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

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

在 Looker 中执行 Git 命令

Looker 具有内置接口，可与您的 Git 服务集成。Looker 在 LookML IDE 的右上角显示 Git 按钮。

Git 按钮会显示不同的选项，具体取决于您在进行更改以及部署到生产环境的过程中所处的阶段。通常，此按钮上显示的选项是您下次采取行动的最佳指南。

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

为 Git 配置项目后，您可以选择 Git Actions 按钮以打开 Git Actions 面板。

Git 操作面板上提供的命令取决于您在更改和部署到生产时所处的位置。

将更改发布到生产环境

借助默认的 Looker Git 集成，Looker 通过以下 Git 工作流提示开发者：

• 提交对开发者当前开发分支的更改（如果您的项目设置为需要测试才能部署，则运行数据测试）
• 将开发分支合并到生产分支中（默认称为 master）
• 将生产分支部署到将向 Looker 最终用户展示的 Looker 生产环境中

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

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

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

如果您看到配置 Git（配置 Git）按钮，而不是本部分介绍的选项，您需要先为项目设置 Git。

查看未提交的更改

LookML IDE 有多个指示标志，当您处于“开发模式”且有未提交的更改时，系统会显示这些指示符，如修改和验证 LookML 文档页面的标记添加、更改和删除部分所述。

您可以从 Git Actions 面板中选择 View Uncomcommit Changes 选项，以获取所有文件的差异摘要。

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

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

要显示单个文件的差异摘要，请从文件菜单中选择 View Changes（查看更改）选项。

提交更改

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

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

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

如果您的项目启用了高级部署模式，则 Git 按钮会显示从主要分支拉取文本。

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

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

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

输入一条消息，简要说明您所做的更改，并取消选中任何您不希望同步的文件旁边的复选框。然后选择提交以提交更改。

检查是否存在未构建的 PDT

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

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

运行数据测试

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

您必须处于开发模式才能运行数据测试。在开发模式下，您可以通过多种方式为项目启动数据测试：

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

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

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

部署到生产环境

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

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

高级部署模式

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

如果您不希望始终针对 Looker 环境的生产分支使用最新提交内容，具有 deploy 权限的开发者可以使用高级部署模式来指定用于 Looker 环境的确切提交内容。这在多环境开发者工作流中很有用，在这种工作流中，每个环境都指向一个不同的代码库版本。它还能让一个或多个开发者或管理员更好地控制已部署到生产环境的更改。

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

• 使用 Looker IDE 中的部署管理器
• 触发网络钩子

• 使用 API 端点

  注意 ：对于启用了高级部署模式的项目，如果项目从未部署到生产环境，则必须使用 Looker IDE 中的部署管理器进行初始部署。在使用高级部署模式的项目进行初始部署时，您无法使用该 API 或网络钩子。初次部署到生产环境后（即使它最初是在没有高级部署模式的情况下部署的），您也可以使用网络钩子或 API，通过高级部署模式将后续更改部署到生产环境中。

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

查看更改的影响

向组织发布更改后，您可以使用内容验证来确保您没有使任何信息中心或已保存的样式失效。如果是，您将有机会解决该问题。

处理典型问题

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

• 放弃您的更改

  有时，您可能需要放弃数据建模更改。如果他们尚未保存，您可以直接刷新或离开此页面，然后接受警告提示。如果您保存了这些更改，则可以按照还原未提交的更改部分中的说明还原未提交的更改。

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

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

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

还原未提交的更改

涉及您的个人开发分支时，如果您不想部署这些更改，可以将其还原。您可以还原项目中所有未提交的更改，也可以仅还原单个文件中的更改。

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

1. 在 Git Actions 面板中选择 Revert to... 选项。
2. 选择还原选项：
   • 如需仅还原未提交的更改，请选择还原未提交的更改。您还可以选择查看更改链接，查看将会还原的更改。
   • 如需还原所有更改（包括未提交的更改和承诺的更改），请选择 Revert to Production
3. 如需完成还原过程，请选择确认。

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

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

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

解决合并冲突

通常，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 Actions 面板中显示的合并警告中选择 files 链接，以查找受影响的文件。
2. 在该文件中，找到包含合并冲突的行，删除您不想保留的文本版本，同时删除所有合并冲突标记。

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

   提示 ：在您的项目中合并所有合并标记，可验证您是否已解决所有冲突标记并删除所有合并标记。请务必移除 LookML 文件中的所有合并标记实例。这些标记将会导致解析错误，进而导致用户无法探索您的数据。

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

现在，您已解决了合并冲突并将正式版解决方案推送到生产环境中，其他开发者可以继续生产环境，继续照常工作。

Git 垃圾回收

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

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