/// 信息 | 功能可用性 * 企业版可用 * 您需要是 n8n 实例所有者、管理员或项目所有者才能设置源代码控制，以及在 Git 之间发送和接收工作内容 ///

• n8n 中的环境: 环境的用途及其在 n8n 中的工作原理。
• n8n 中的 Git: n8n 如何使用 Git。
• 分支模式: n8n 实例与 Git 分支之间可能的关系模式。

n8n 中的环境管理#

n8n 的环境功能构建在版本控制软件 Git 之上。本文档将帮助您理解：

• 环境管理的目的
• 环境在 n8n 中的工作原理

环境管理：概念与意义#

在软件开发中，环境指的是围绕代码的所有基础设施和工具，包括运行软件的工具体系及其特定配置。如需深入了解软件开发中的环境概念，请参考 Codecademy | 环境管理。

n8n 的低代码开发同理。n8n 是您构建和运行工作流的平台。您的实例可能具有特定配置：在云端版本中，n8n 负责决定配置；而在自托管实例中，则提供丰富的配置选项。您可能还对实例设置进行了调整。n8n 平台与这些特定配置及设置的组合，就构成了您工作流的运行环境。

维护多个环境具有显著优势。常见的模式是为开发和生产设置不同环境：

• 开发环境：用于实施变更和调试工作
• 生产环境：实际运行的线上环境

这种架构设计能让您在修改工作流时，避免影响正在使用中的生产流程。

n8n 中的环境#

在 n8n 中，一个环境由两部分组成：n8n 实例和 Git 分支：

• n8n 实例是您构建和运行工作流的地方
• Git 分支存储工作流的副本，以及标签、变量和凭据存根

n8n 不会将凭据和变量值与 Git 同步。在设置新实例时，您必须手动配置凭据和变量值。更多信息请参阅推送与拉取 | 提交内容。

在不同环境间复制工作的方式取决于您的分支和 n8n 实例配置：

• 多实例单分支：您可以从一个实例推送到 Git 分支，然后将工作拉取到另一个实例
• 多实例多分支：您需要在 Git 提供商处创建拉取请求并合并。例如，如果您有开发、测试和生产分支，每个分支都链接到各自的实例，您需要将开发分支合并到测试分支，才能使开发实例的工作在测试实例上可用。更多信息请参阅在环境间复制工作，包括部分自动化流程的步骤

Git 与 n8n#

n8n 使用 Git 提供源代码控制功能。要使用此功能，了解基本的 Git 概念会有所帮助。n8n 并未实现所有 Git 功能：您不应将 n8n 的源代码控制视为完整的版本控制系统。

初次接触 Git 和源代码控制？

如果您是 Git 新手，请不要担心。使用 n8n 并不需要学习 Git。本文档会解释您需要的概念。不过在设置源代码控制时确实需要一些 Git 知识，因为这涉及到在您的 Git 提供商处进行操作。

熟悉 Git 和源代码控制？

如果您熟悉 Git，请不要依赖完全匹配的行为。特别需要注意的是，n8n 中的源代码控制不支持拉取请求(pull request)式的审查和合并流程，除非您在 n8n 之外的 Git 提供商处进行此操作。

本页介绍 n8n 中使用的 Git 概念和术语。它不涵盖设置和管理仓库所需的全部内容。进行设置的人员应该对 Git 及其 Git 托管提供商有一定了解。

这是简要介绍

Git 是一个复杂的主题。本节简要介绍在 n8n 中使用环境时需要了解的关键术语。

Git 概述#

Git 是一个用于管理、跟踪和协作处理文档多版本的工具。它是 GitHub 和 GitLab 等广泛使用平台的基础。

分支：项目的多版本并行管理#

Git 使用分支来维护文档的多个并行版本。每个分支都拥有独立的版本内容。常见的模式是维护一个主分支（main branch），所有项目贡献者都在自己的分支（副本）上工作。当他们完成工作时，将分支合并回主分支。

本地与远程：在本地机器和 Git 提供商之间同步工作#

使用 Git 的常见模式是在本地计算机上安装 Git，同时使用 GitHub 等 Git 提供商进行云端协作。实际上，您在 GitHub 上拥有一个 Git 仓库（项目），并在本地机器上操作其副本。

n8n 采用这种模式进行源码控制：您将在 n8n 实例上操作工作流，但将它们推送到 Git 提供商进行存储。

推送、拉取与提交#

n8n 使用三个关键的 Git 流程：

• 推送（Push）：将工作从您的实例发送到 Git。这会将您的工作流、标签以及凭证和变量的存根保存到 Git。您可以选择要保存哪些工作流。

• 拉取（Pull）：从 Git 获取工作流、标签和变量并加载到 n8n 中。您需要为刷新项目中包含的任何凭证或变量存根填充实际值。

  拉取操作会覆盖本地修改

  如果您已在 n8n 中修改了工作流，必须在拉取前将更改推送到 Git。拉取操作会覆盖所有未存储在 Git 中的本地更改。

• 提交（Commit）：在 n8n 中，提交是指单次将工作推送到 Git 的操作。n8n 中的提交和推送是同步进行的。

分支模式#

n8n 实例与 Git 分支之间的关系是灵活的。您可以根据需求创建不同的设置方案。

/// 注意 | 建议：不要向同一个 n8n 实例同时执行推送和拉取操作 您可以将工作从一个实例推送到分支，也可以拉取到同一个实例。但 n8n 不建议这样做。为了减少合并冲突和覆盖工作的风险，请尽量创建一个单向的工作流程：要么推送到 Git，要么从 Git 拉取，但不要同时进行双向操作。 ///

多实例多分支模式#

这种模式涉及多个 n8n 实例，每个实例都关联到自己的分支。

您可以将此模式用于环境管理。例如，创建两个 n8n 实例：开发环境和生产环境。将它们分别关联到各自的分支。从开发实例推送工作到其分支，通过拉取请求将工作转移到生产分支，然后拉取到生产实例。

这种模式的优点包括：

• 增加了一个安全层，防止变更意外进入生产环境。您需要在 GitHub 上发起 pull request 才能在环境间复制工作流程。
• 支持两个以上的环境实例。

缺点是环境间复制工作流程需要更多手动操作步骤。

多实例单分支模式#

如果您希望在所有地方使用相同的工作流、标签和变量，但要在不同的 n8n 实例中使用，可以采用这种模式。

您可以将此模式用于环境管理。例如，创建两个 n8n 实例：开发环境和生产环境。将它们都关联到同一个分支。从开发环境推送工作，然后拉取到生产环境。

这种模式在测试新版本 n8n 时也很有用：您可以创建一个带有新版本的 n8n 实例，将其连接到 Git 分支进行测试，而生产实例则保持在旧版本，直到您确认升级安全为止。

这种模式的优点是：当您从一个实例推送时，工作内容会立即对其他环境可用。

其缺点包括：

• 如果误操作推送，存在工作内容进入生产环境的风险。如果您使用 GitHub Action 自动拉取到生产环境，必须采用多实例多分支模式，或者小心确保绝不推送不希望进入生产环境的内容。
• 向同一实例进行推送和拉取操作可能导致数据丢失，因为这些操作会覆盖变更。您应建立流程确保内容单向流动。

单实例多分支模式#

实例所有者可以更改实例连接的 Git 分支。这种情况下完整的设置很可能是多实例多分支模式，但单个实例会在不同分支间切换。

这种模式适用于代码审查场景。例如，不同用户可以在自己的实例上工作并推送到各自的分支。审查者可以在一个审查实例中工作，通过切换分支来加载不同用户的工作内容。

无清理机制

当切换分支时，n8n 不会清理实例中现有的内容。在这种模式下切换分支会导致所有分支的工作流都保留在您的实例中。

单实例单分支模式#

这是最简单的模式。

《AI提示工程必知必会》为读者提供了丰富的AI提示工程知识与实战技能。《AI提示工程必知必会》主要内容包括各类提示词的应用，如问答式、指令式、状态类、建议式、安全类和感谢类提示词，以及如何通过实战演练掌握提示词的使用技巧；使用提示词进行文本摘要、改写重述、语法纠错、机器翻译等语言处理任务，以及在数据挖掘、程序开发等领域的应用；AI在绘画创作上的应用，百度文心一言和阿里通义大模型这两大智能平台的特性与功能，以及市场调研中提示词的实战应用。通过阅读《AI提示工程必知必会》，读者可掌握如何有效利用AI提示工程提升工作效率，创新工作流程，并在职场中脱颖而出。