分支模式#

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

建议：不要在同一个n8n实例中推送和拉取

您可以从一个实例向分支推送工作，并拉取到同一个实例。n8n 不建议这样做。为了降低合并冲突和覆盖工作的风险，请尝试创建一个工作单向流动的流程：要么流向 Git，要么来自 Git，但不要双向。

多个实例，多个分支#

此模式涉及拥有多个 n8n 实例，每个实例链接到自己的分支。

您可以将此模式用于环境。例如，创建两个 n8n 实例，开发和生产。将它们链接到各自的分支。从开发实例推送工作到其分支，创建拉取请求将工作移动到生产分支，然后拉取到生产实例。

这种模式的优势包括：

缺点是在环境之间复制工作需要更多手动步骤。

如果您希望在各处拥有相同的工作流、标签和变量，但希望在不同的 n8n 实例中使用它们，请使用此模式。

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

此模式在测试新版本的 n8n 时也很有用：您可以使用新版本创建新的 n8n 实例，将其连接到 Git 分支并进行测试，而您的生产实例保持在较旧版本上，直到您确信升级是安全的。

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

缺点包括：

如果您意外推送，工作有可能进入您的生产实例。如果您使用 GitHub Action 自动拉取到生产环境，您必须使用多实例、多分支模式，或者小心不要推送您不希望在生产环境中出现的工作。
在同一实例中推送和拉取可能会导致数据丢失，因为在执行这些操作时更改会被覆盖。您应该建立流程来确保内容单向流动。

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

这对于审查工作很有用。例如，不同的用户可以在自己的实例上工作并推送到自己的分支。审查者可以在审查实例中工作，并在分支之间切换以加载来自不同用户的工作。

无清理

n8n 在更改分支时不会清理实例的现有内容。在此模式下切换分支会导致每个分支的所有工作流都在您的实例中。

这是最简单的模式。