分支模式#

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

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

多实例多分支模式#

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

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

这种模式的优点包括：

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

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

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

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

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

其缺点包括：

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

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

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

无清理机制

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

这是最简单的模式。