分支模式#
n8n 实例与 Git 分支之间的关系是灵活的。你可以根据需要创建不同的配置。 建议：不要向同一个 n8n 实例同时进行推送（push）和拉取（pull） 你确实可以将某个实例的工作推送到分支，并从同一实例拉取更新，但 n8n 不推荐这种做法。为了降低合并冲突（merge conflicts）和覆盖他人工作的风险，建议建立一个单向流程：工作要么只推送到 Git，要么只从 Git 拉取，而不是双向操作。
多实例多分支#
该模式包含多个 n8n 实例，每个实例分别关联到独立的分支。
你可以使用此模式来管理不同环境。例如，创建两个 n8n 实例：开发（development）和生产（production），并将其各自连接到对应的分支。从开发实例将变更推送到其对应分支，通过发起 Pull Request 将更改合并至生产分支，然后在生产实例中执行拉取操作以同步更新。
该模式的优点包括：
- 提供额外的安全层，防止意外将变更引入生产环境。必须通过 GitHub 的 Pull Request 才能在环境之间传递变更。
- 支持两个以上的实例配置。
缺点是需要更多手动步骤在不同环境之间复制工作内容。
多个实例，一个分支#
如果你希望在所有环境中使用相同的 workflow、标签（tags）和变量（variables），但将它们部署在不同的 n8n 实例中，可以采用此模式。
你可以将该模式用于不同环境的管理。例如，创建两个 n8n 实例：开发（development）和生产（production）。将这两个实例都连接到同一个 Git 分支。从开发环境推送更改，并将其拉取到生产环境中。
此模式在测试新版本的 n8n 时也非常有用：你可以创建一个运行新版本的 n8n 实例，将其连接到同一 Git 分支进行测试，而你的生产实例仍保持在旧版本上，直到你确认升级是安全的。
该模式的优点是：当你从一个实例推送更改后，其他环境会立即获得这些更新。
缺点包括：
- 如果误操作进行了推送，可能会导致未完成或错误的工作进入生产环境。如果你使用 GitHub Action 自动化拉取操作到生产环境，则必须要么改用“多实例多分支”模式，要么格外小心，确保不会推送不希望进入生产环境的内容。
- 对同一实例频繁执行推送和拉取操作可能导致数据丢失，因为这些操作会覆盖现有更改。你应该建立流程规范，确保内容只沿一个方向流动。
一个实例，多个分支#
实例所有者可以更改连接到该实例的 Git 分支。在这种情况下，完整的设置可能原本是 多个实例，多个分支 模式，但仅使用一个实例在不同分支之间切换。
这种模式适用于代码或工作内容的审查。例如，不同的用户可以在各自的实例上工作，并将更改推送到自己的分支；审查人员则可在专门的审查实例中，通过切换分支来加载并查看不同用户的工作内容。
无清理机制 n8n 在切换分支时不会清除实例中已有的内容。因此，在此模式下切换分支会导致来自各个分支的所有工作流都保留在你的实例中。
一个实例，一个分支#
这是最简单的模式。