AI 一次改崩几十个文件，普通人怎么用 Git 回到可用版本？

你让 AI 修改一个项目，它改完以后，整个东西突然不能用了。

更麻烦的是，它刚才动的不是一个文件，而是十几个、几十个文件。你只记得“上一版还能用”，却不知道哪些地方被改过，也不知道怎样完整退回去。

这种时候，继续对 AI 说“帮我改回原来的样子”，往往不可靠。因为 AI 只能再猜一次，而你真正需要的是一条保存过的时间线。

这就是版本管理：每到一个确定可用的节点，就把当时所有文件的状态保存下来。后面无论改了多少次，都可以查看差异，或者回到任意一个保存过的版本。

我现在做的“个人 IP 内容工程”，里面不只有文案，还包括视频、动画、网站、自动化流程和各种规则文件。AI 每天可能同时修改很多文件。如果没有版本管理，项目越大，反而越脆弱。

Git 就是最常用的版本管理工具。它看起来像程序员的东西，但你不需要先学会敲一堆命令。这篇文章只要求你先看懂几个概念，再把 Git 和 GitHub 的连接准备好。准备完成后，初始化、保存、同步和恢复，都可以直接用大白话让 AI 操作。

先分清 Git、GitHub 和 gh

这三个名字经常一起出现，但它们不是一回事。

• Git：负责在你的电脑里记录版本。没有网络也能用。
• GitHub：负责把仓库放到远程，方便备份、同步和协作。
• gh：GitHub 官方的命令行工具，全名 GitHub CLI。AI 可以调用它来登录 GitHub、创建仓库和同步文件。

可以把它们理解成：Git 是本地的版本档案系统，GitHub 是远程保险柜，gh 是连接和操作这个保险柜的官方工具。

用一篇论文，看懂 Git 的六个核心概念

假设你正在写一篇论文。

1. 仓库 Repo：装下整个项目的档案袋

仓库不是某一个文件，而是一个由 Git 管理的完整项目文件夹。论文正文、参考资料、图片和配置，都可以放在同一个仓库里。

2. 提交 Commit：给当前状态拍一张快照

论文写完第一章，确认现在这版能用，你就保存一次提交。它不是普通的“按一下保存”，而是给这一刻的项目状态留下一张带说明的快照。

说明要写清楚，例如“完成第一章初稿”，不要只写“改了一下”。以后你才能快速判断该回到哪一版。

3. 推送 Push：把本地版本同步到远程

提交先保存在你的电脑里。推送，就是把已经提交的版本同步到 GitHub。这样即使电脑损坏，远程仍然保留一份版本记录。

4. 拉取 Pull：把远程的新版本拿回本地

如果你在另一台电脑上改过论文，或者合作者把新内容同步到了 GitHub，拉取就是把远程的最新版本拿回当前电脑。

5. 分支 Branch：在副本时间线上放心试错

你想大改论文结构，但又不想破坏当前可用版本，就可以开一条分支。主版本继续保持稳定，你在另一条时间线上实验。

6. 合并 Merge：把验证过的修改放回主版本

实验确认没问题后，再把分支中的改动合并回主版本。如果实验失败，直接放弃这条分支，原来的稳定版本不受影响。

第一次实践时，你真正需要掌握的是前三个：仓库、提交、推送。拉取、分支和合并先知道用途，等项目真的需要时再用。

开始前准备什么

准备一个不含隐私信息的测试文件夹，里面放一份随时可以丢弃的文档。第一次不要直接拿重要项目练习。

你还需要：

1. 一个 GitHub 账号。
2. 电脑已经安装 Git。
3. 电脑已经安装 GitHub CLI，也就是 gh。
4. 一个能访问这个文件夹并执行本地操作的 AI 工具，例如 Codex 或其他代码 Agent。

先让 AI 帮你检查：

请只检查当前电脑是否已经安装 Git 和 GitHub CLI，分别告诉我版本号。先不要修改任何文件，也不要登录账号。

如果能看到 Git 和 gh 的版本号，就可以进入登录步骤。如果缺少其中一个，再按下面的方法安装。

安装 Git 和 GitHub CLI

macOS

Git 可以从 Git 官方 macOS 安装页 获取。已经使用 Homebrew 的人，可以安装 Git 和 gh：

brew install git
brew install gh

不使用 Homebrew，也可以在终端运行 xcode-select --install 安装 Apple 提供的命令行工具，其中包含 Git。gh 仍建议按 GitHub CLI 官网 给出的方式安装。

安装完成的标准：重新打开终端或 AI 工具后，git --version 和 gh --version 都能显示版本号。

Windows

最直观的方法，是打开 Git for Windows 官方下载页 安装 Git，再到 GitHub CLI 官网 下载 Windows 安装包。GitHub CLI 提供 x64 和 ARM64 的 MSI 安装程序，按自己电脑的类型选择即可。

如果你的 Windows 已经可以使用 WinGet，也可以按 Win 键，输入 PowerShell 并回车，然后安装：

winget install --id Git.Git -e --source winget
winget install --id GitHub.cli -e --source winget

WinGet 在较新的 Windows 10、Windows 11 上通常随“应用安装程序”提供，但并不是每台电脑都一定可用。如果输入 winget 没有反应，直接使用上面的官方安装包，不需要额外折腾。

安装完成后，关闭并重新打开 PowerShell、终端或 AI 工具，再检查 Git 和 gh 的版本号。

不建议为了安装 gh 去找来路不明的 npm 包。gh 是独立的官方工具，优先使用 GitHub 官网、Homebrew、WinGet 或官方 MSI 安装包。

用浏览器完成 GitHub 授权

工具装好，还需要让这台电脑获得访问你 GitHub 账号的许可。最省心的方式不是复制 classic token，而是使用 gh 的浏览器登录。

在终端运行：

gh auth login --web

然后按提示完成：

1. 主机选择 GitHub.com。
2. Git 操作协议选择 HTTPS。
3. 选择使用 GitHub 账号完成认证。
4. gh 会显示一次性设备码并打开浏览器；如果没有自动打开，就复制终端里的网址到浏览器。
5. 在浏览器登录 GitHub，核对设备码并批准授权。
6. 回到终端，等待成功提示。

这是 GitHub CLI 官方支持的网页认证流程。密码和授权操作留在浏览器里，不需要把 classic token 复制给 AI。具体选项以后可能调整，以 gh 登录官方说明 为准。

授权后运行：

gh auth status
gh auth setup-git

成功标准是：gh auth status 显示已经登录 github.com，并能看到当前账号；gh auth setup-git 没有报错。不要运行会输出令牌的命令，也不要把任何 token 发进聊天窗口、截图或文档。

第一次用大白话保存版本

下面只在刚才准备的测试文件夹里操作。每一次都先让 AI 解释计划，再让它执行，这样你能把动作和概念对应起来。

第一步：初始化仓库

把测试文件夹交给 AI，然后说：

先检查这个测试文件夹。告诉我里面有哪些文件，以及你准备怎样把它初始化成 Git 仓库。不要修改文件内容；说明计划后再执行。

为什么先这样做：初始化只是在这个文件夹里建立 Git 的版本记录能力，不应该顺手改正文。

成功标准：AI 明确告诉你仓库已经初始化；再次检查时，当前文件夹被识别为 Git 仓库，但原文内容没有变化。

第二步：保存第一个可用版本

接着说：

把当前内容保存成第一个 Git 版本，提交说明写“初始可用版本”。执行后告诉我保存了哪些文件，并确认当前是否还有未保存的改动。

为什么要写说明：以后版本多了，“初始可用版本”比“第一次”更容易识别。

成功标准：AI 告诉你提交已经完成，并且当前没有未保存的改动。如果它提示缺少 Git 用户名或邮箱，让它先解释用途，再使用你确认的公开身份配置；这里不需要 GitHub 密码。

第三步：创建私人 GitHub 仓库并同步

最后说：

请根据当前文件夹创建一个私人的 GitHub 仓库，并把刚才的版本同步上去。不要改成公开仓库。执行前先告诉我仓库名称和将要运行的操作，完成后给我仓库地址并检查同步是否成功。

gh 官方支持从当前目录创建仓库并推送已有提交，相关参数可以在 gh repo create 官方说明 查看。你不需要背这些参数，但应该知道 AI 正在做的是“创建私人远程仓库 + 连接本地仓库 + 推送已提交版本”。

成功标准：GitHub 上出现一个 Private 仓库；仓库页面能看到测试文档和“初始可用版本”这次提交；AI 检查后确认本地与远程一致。

故意改坏一次，再把它恢复

只有真正恢复过一次，你才会建立对版本管理的信心。

先让 AI 修改测试文档，例如删除一段内容、改掉标题，并明确要求暂时不要提交：

这是一次恢复练习。请把测试文档的标题和其中一段内容改掉，但先不要提交。完成后列出修改差异。

确认文件已经被改坏后，再说：

请把这些尚未提交的修改恢复到“初始可用版本”的状态。不要删除 Git 历史，也不要重建仓库。执行前先说明会恢复哪些文件，完成后检查内容和 Git 状态。

成功标准：打开测试文档，确认标题和被删掉的那段文字都恢复到第一次提交时的内容；“初始可用版本”仍然存在；当前没有未保存的改动。

这里特意强调“尚未提交的修改”，因为恢复已经提交并推送的历史需要先判断是否影响其他人，处理方式也不同。等你遇到真实场景时，让 AI 先展示版本记录和影响，再决定恢复方案，不要一上来就让它强行覆盖历史。

让 AI 操作，但不要放弃自己的判断

AI 可以替你运行 Git，但你至少要能回答四个问题：

1. 现在操作的是哪个仓库？
2. 这次改了哪些文件？
3. 是否已经提交，提交说明是什么？
4. 是否已经推送到正确的私人远程仓库？

如果 AI 只说“完成了”，你可以继续追问它展示检查结果。版本管理的价值不是让操作显得专业，而是让每次改动都有记录、能验证、能恢复。

最后给一个适合长期项目的小建议：可以在项目的 AGENTS.md 或同类规则文件中约定，AI 每次完成一组明确修改后，都要用自己的话总结改动，创建一次提交，并在你授权的情况下同步远程。这样版本保存会变成流程的一部分，而不是出问题后才想起来补救。

但不要把“自动提交”理解成“什么都自动推送”。涉及隐私、密钥、大文件或未完成实验时，仍然要先检查哪些文件会进入仓库。

你现在只做这一件事

不要从重要项目开始，也不用一次学完所有 Git 命令。

新建一个只有一份文档的测试文件夹，完成这条最小链路：

检查安装 → 浏览器登录 gh → 初始化仓库 → 保存第一个版本 → 创建私人 GitHub 仓库 → 故意改坏 → 恢复。

当你亲手验证过一次“改坏了也能完整回来”，Git 就不再是一组陌生命令，而会变成你和 AI 一起做长期项目时的安全时间线。