[OPS] 从 GitHub 恢复工作流到 n8n

此工作流适合以下人群：
- 开发者：需要将 GitHub 上的工作流备份恢复到 n8n。
- 团队协作成员：需要确保团队中的所有人都能访问最新的工作流版本。
- 项目经理：希望通过自动化流程来提高工作效率，减少手动操作的错误。
- DevOps 工程师：需要在持续集成和持续部署过程中管理工作流。

此工作流解决了以下问题：
- 数据丢失风险：通过从 GitHub 恢复工作流，减少因意外删除或丢失导致的工作流数据丢失风险。
- 版本管理：确保所有工作流都保持最新状态，避免使用过时的版本。
- 效率低下：通过自动化恢复流程，节省手动操作的时间，提高团队的整体效率。

工作流的详细步骤如下：
1. 手动触发：用户点击执行按钮以启动工作流。
2. 设置全局变量：定义 GitHub 仓库的所有者、名称和工作流路径。
3. 获取 GitHub 文件：从指定的 GitHub 仓库中列出所有文件。
4. 获取每个文件：逐个获取文件内容，并将其解码为 JSON 格式。
5. 设置名称和内容：为每个文件设置工作流名称和内容。
6. 获取 n8n 中的所有工作流：列出当前 n8n 实例中的所有工作流以进行比较。
7. 合并工作流：将 GitHub 和 n8n 的工作流进行合并，保留仅在 GitHub 中存在而不在 n8n 中的工作流。
8. 检查工作流是否已存在：判断要创建的工作流是否在 n8n 中已存在，以避免重复。
9. 创建 n8n 工作流：对于不存在的工作流，将其创建在 n8n 中。

用户可以通过以下方式自定义和调整此工作流：
- 修改 GitHub 仓库信息：在 Globals 节点中更新 repo.owner、repo.name 和 repo.path 以匹配自己的 GitHub 配置。
- 调整工作流逻辑：根据需要修改条件节点，以便在不同情况下执行不同的操作。
- 添加额外的节点：根据需求在工作流中添加更多的处理节点，以实现更复杂的逻辑。
- 修改通知方式：可以在工作流中添加通知节点，以便在工作流执行完成后向相关人员发送通知。