分支模式#

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

多实例与多分支#

该模式涉及运行多个n8n实例，每个实例都连接到自己的分支。

您可以将此模式应用于环境设置。例如，创建两个n8n实例：开发环境和生产环境。将它们分别关联到各自的分支。从开发实例推送工作内容至其对应分支，通过拉取请求将工作迁移至生产分支，最后拉取到生产实例中。

这种模式的优势是：

• 新增的安全层，防止变更意外进入生产环境。您需要在GitHub上发起拉取请求才能在环境之间复制工作流程。
• 它支持两个以上的实例。

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

多个实例，一个分支#

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

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

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

这种模式的优点是，当你从一个实例推送时，工作可以立即在其他环境中使用。

缺点包括：

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

单一实例，多个分支#

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

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

一个实例，一个分支#

这是最简单的模式。