别再手动备份 JSON 文件了，Git 才是 n8n 工作流的终极归宿
笔者在 N8N 大学接触过无数用户，发现大家最头疼的不是写流程，而是“丢了流程”。把 n8n 搭在本地还好，一旦部署在服务器上，手滑误删、升级崩溃、甚至团队协作时代码冲突，都可能让你前功尽弃。
还在用“导出 JSON”、“另存为”这种上古方式备份？这就像用 U 盘拷贝代码一样原始。今天，笔者就带你用最硬核的方式——Git，给你的 n8n 工作流加上企业级的版本控制。
为什么 n8n 原生导出不够用？
n8n 的 JSON 导出功能本质上是“快照”，它无法记录变更历史，也无法进行差异对比。如果两个同事同时修改了同一个工作流，你很难合并他们的改动，通常只能二选一。
而 Git 是目前世界上最先进的分布式版本控制系统。它能让你：
- 回滚：瞬间撤销错误的修改，回到上一个稳定版本。
- 分支：开发新功能时不影响线上运行的旧版本。
- 协作：多人开发 n8n 工作流，像管理代码一样管理自动化。
实战：将 n8n 工作流纳入 Git 管理
在开始之前，请确保你已经准备好了以下条件：
- 一个运行中的 n8n 实例（建议是 Docker 部署或服务器版）。
- 服务器终端访问权限（SSH）。
- 一个 Git 仓库（GitHub、GitLab 或 Gitee 均可）。
第一步：定位 n8n 的工作流存储路径
默认情况下，n8n 的工作流和凭证数据存储在 SQLite 数据库中（`n8n.db`），这不利于 Git 管理。我们需要先将数据导出为文件格式。
如果你是使用 Docker 部署，通常可以通过映射卷来访问。但更推荐的方式是直接使用 n8n 的 Webhook 节点 或 n8n CLI 来导出。不过，最简单的实操方法是利用 n8n 的 Git 集成插件。
在 n8n 的社区版中，我们可以通过环境变量配置，或者使用第三方工具将工作流同步到本地目录。
笔者提醒：如果你的 n8n 是直接通过 npm 安装的，工作流文件通常位于 `~/.n8n` 目录下。如果是 Docker，你需要进入容器内部查看。
第二步：初始化本地 Git 仓库
假设我们已经通过脚本将工作流导出到了服务器的 `/opt/n8n-workflows` 目录。现在，我们在这个目录下初始化 Git。
cd /opt/n8n-workflows git init git add . git commit -m "Initial commit: n8n workflows backup"
这里有一个关键点：**n8n 的 JSON 文件包含敏感信息（如 API Key、Webhook URL）**。绝对不能直接推送到公开仓库！
你需要创建一个 .gitignore 文件，排除敏感数据和缓存文件：
# .gitignore *.env credentials.json .cache
第三步：连接远程仓库并推送
将本地仓库与远程仓库关联。以 GitHub 为例：
git remote add origin https://github.com/你的用户名/n8n-workflows.git git branch -M main git push -u origin main
至此，你的 n8n 工作流已经完成了第一次代码级备份。每次修改工作流后，只需执行 git add . && git commit -m "描述你的改动" 即可。
第四步：自动化同步（进阶）
手动提交虽然可行，但容易忘记。我们可以利用 n8n 的 Exec 节点 或系统的 Cron Job 来自动同步。
创建一个新的 n8n 工作流：
- 触发器：Schedule（定时触发，例如每小时一次）。
- 节点：Exec（执行 Shell 命令）。
- 命令内容：
cd /opt/n8n-workflows && git add . && git commit -m "Auto backup" && git push
这样，即使你忘记了手动备份，系统也会帮你兜底。
避坑指南：实战中容易踩的坑
在使用 Git 管理 n8n 工作流时，笔者见过最多的两个报错如下：
1. 文件权限错误 (Permission denied)
如果你的 n8n 运行在 Docker 容器中，且通过宿主机的 Git 操作，经常会遇到权限问题。这是因为在容器内运行的 n8n 用户（通常是 `node` 或 `root`）与宿主机的 Git 用户不一致。
解决方案：在 Docker Compose 中显式指定用户 ID。
user: "1000:1000"
确保宿主机的文件权限允许该用户读写。
2. JSON 文件冲突
n8n 的 JSON 文件结构复杂，且包含生成的 ID。如果两个人同时修改了同一个工作流，Git 很难自动合并，通常会报 CONFLICT (content)。
解决方案：分工明确。尽量避免多人同时编辑同一个工作流。如果必须，建议使用 n8n 的 Copy 功能复制一份新的工作流进行修改，而不是直接修改源文件。或者，使用 VS Code 等编辑器手动解决 JSON 冲突（对比差异）。
FAQ：n8n 与 Git 的常见问题
Q1: 为什么不直接用 n8n 的云服务自带版本控制？
A: n8n Cloud 确实有基本的版本历史，但它受限于服务商。使用 Git 意味着你拥有数据的完全所有权，可以跨平台迁移，且历史记录永不过期。这是自托管 n8n 的核心优势之一。
Q2: 我的凭证（Credentials）也能用 Git 管理吗？
A: 绝对不要！ n8n 的凭证是加密存储的，但导出为 JSON 时可能包含明文密钥。Git 会永久记录这些敏感信息（即使删除文件，历史记录还在）。请使用环境变量或 n8n 内置的密钥管理功能，仅对工作流逻辑进行版本控制。
Q3: 这种方法适用于 n8n 1.0 以后的版本吗？
A: 是的。虽然 n8n 在 1.0 版本对数据存储结构做了调整，但核心逻辑不变。只要你的 n8n 实例能访问到 Git 仓库，无论是 0.x 还是 1.x，这套方法都通用。
总结与资源
将 n8n 工作流纳入 Git 管理，是从“玩票”走向“生产级应用”的关键一步。它不仅提供了安全网，更让你的自动化流程具备了工程化的严谨性。
在 N8N 大学，我们始终建议：像管理代码一样管理你的自动化。这是通往高阶玩家的必经之路。
相关资源推荐：
- N8N 大学官方文档：https://n8ndx.com
- n8n 官方 GitHub 仓库：https://github.com/n8n-io/n8n
