分支模式

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

多实例，多分支

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

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

这种模式的优点是：

• 增加了安全层，防止更改被误入生产环境。您必须在 GitHub 上发起拉取请求才能在环境之间复制工作。
• 它支持两个以上的实例。

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

多个实例，一个分支

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

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

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

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

缺点是：

• 如果您错误地推送了代码，则可能会将工作内容推送到您的生产实例。如果您使用 GitHub Action 自动执行拉取到生产环境的操作，则必须使用多实例、多分支模式，或者注意不要推送您不想在生产环境中使用的工作内容。
• 推送和拉取到同一个实例可能会导致数据丢失，因为执行这些操作时更改会被覆盖。您应该设置流程以确保内容单向流动。

一个实例，多个分支

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

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

一个实例，一个分支

这是最简单的模式。