Git & GitHub for Vibe Coders：AI 编程时代的版本控制白话指南
Git & GitHub for Vibe Coders：AI 编程时代的版本控制白话指南
本文面向使用 Claude Code、Cursor 等 AI 编程工具，但没有传统开发背景的朋友。
你不需要一开始就背熟所有 Git 命令，但必须理解 Git 的核心机制：
如何存档、如何回退、如何隔离风险、如何与 AI / 团队协作。
如果你经常看到 AI 弹出这些词：
commit
branch
push
pull
PR
merge
conflict
restore
revert
worktree
不要被吓到。本文会用最白话的方式，把 Git 和 GitHub 讲清楚，并教你如何用自然语言指挥 AI 正确操作版本控制。
一、先建立心智模型：Git 不是网盘，GitHub 也不是普通云盘
很多初学者会误以为：
Git = 上传代码的工具
GitHub = 存放代码的网盘
这个理解不够准确。
更准确的说法是：
Git 是本地的版本控制系统。
GitHub 是基于 Git 的代码托管与协作平台。
你可以这样理解：
| 概念 | 白话比喻 | 真实作用 |
|---|---|---|
| Git | 本机版本追踪器 / 游戏存档系统 | 记录代码每次变化，让你可以回退、比较、恢复 |
| GitHub | 代码专用的云端仓库 / 团队协作平台 | 存放 Git 提交历史，方便备份、协作、审查代码 |
| commit | 手动游戏存档 | 在本地记录一个安全版本 |
| push | 把存档同步到云端 | 将本地提交上传到 GitHub |
| pull | 从云端拉取最新进度 | 把远程最新代码同步到本地 |
| branch | 平行时空实验沙盒 | 在不影响主线的情况下开发新功能 |
| PR | 修改提案 | 请别人审查你的代码，再决定是否合并 |
| merge | 合并分支 | 把实验分支的成果并入正式主线 |
重点一句话：
GitHub 不是简单接收文件夹，它接收的是 Git 管理好的提交历史。
GitHub 网页确实可以手动上传少量文件，但真正的版本管理、协作、回退、审查，都依赖 Git 的提交记录。
二、Git 与 GitHub 的关系
1. GitHub：代码托管平台
GitHub 是一个网站，用来：
- 存放代码仓库。
- 备份代码。
- 多人协作。
- 提交 PR。
- 审查代码。
- 管理 Issue。
- 发布 Release。
- 配置 CI/CD 自动化流程。
你可以把它理解成：
代码的云端仓库 + 团队协作平台
但它不是普通网盘。
普通网盘同步的是文件。
GitHub 同步的是：
谁在什么时间
基于哪个版本
改了哪些文件
为什么改
是否经过审查
2. Git：本地版本管理工具
Git 安装在你自己的电脑上。
它负责：
- 追踪文件变化。
- 记录每次提交。
- 创建分支。
- 合并代码。
- 解决冲突。
- 回退版本。
- 与 GitHub 同步。
你可以把 Git 理解成：
代码世界的时光机
每次 commit，都是给当前项目拍一张快照。
以后如果代码被 AI 改坏了，你可以回到之前某个正常的快照。
3. git init：开始追踪这个项目
如果你有一个本地项目文件夹，想让 Git 开始管理它，可以执行：
git init
它的作用是：
在当前文件夹里初始化一个 Git 仓库。
执行之后，当前文件夹就会变成一个 Git 可管理的项目。
你可以理解为：
告诉 Git：从现在开始，帮我记录这个文件夹里的变化。
三、Git 的四个关键区域
要真正理解 Git，建议先记住四个区域。
工作区
↓ git add
暂存区
↓ git commit
本地仓库
↓ git push
远程仓库
1. 工作区 Working Directory
就是你电脑上能看到的文件。
比如：
index.html
app.js
package.json
.env
你正在编辑的这些文件，就属于工作区。
白话理解：
你的办公桌。
2. 暂存区 Staging Area
暂存区是你准备提交的一组改动。
比如你改了 10 个文件，但这次只想提交其中 3 个文件。
你可以先把这 3 个文件放进暂存区：
git add file1.js file2.js file3.js
或者把当前所有改动都加入暂存区：
git add .
白话理解：
打包前的纸箱。
你先把要存档的东西放进纸箱，但还没封箱。
3. 本地仓库 Local Repository
执行 commit 后，暂存区的内容会被保存到本地 Git 仓库。
git commit -m "feat: add login page"
白话理解：
本机游戏存档。
注意：
commit 只保存在你自己电脑上，不会自动上传到 GitHub。
4. 远程仓库 Remote Repository
远程仓库通常在 GitHub 上。
执行 push 后，本地提交才会上传到 GitHub。
git push
白话理解：
把本机存档同步到云端备份。
四、单人开发最重要的两个动作：Commit 与 Push
1. Commit：本机存档
Commit 是什么？
Commit 是给当前代码状态建立一个版本记录。
你可以把它理解成：
打 Boss 前的手动存档。
如果后面 AI 把代码改坏了，你可以回到这个存档。
Commit 的正确时机
建议在以下情况提交：
- 一个功能完成了一小步。
- 测试通过。
- 代码可以正常运行。
- 一个 bug 修复完成。
- AI 准备进行大范围修改前。
- 你想保存当前可工作的版本。
不要等到一天结束才提交一次。
更好的方式是：
小步提交，频繁存档。
Commit 命令示例
查看当前状态：
git status
查看具体改动：
git diff
把改动加入暂存区：
git add .
提交：
git commit -m "feat: add coupon claim button"
Commit Message 建议
不要写：
update
fix
修改
改了一点东西
AI 帮我改的
建议写清楚：
feat: add coupon claim button
fix: prevent expired coupon from being claimed
docs: update installation guide
refactor: extract coupon validation logic
test: add tests for coupon expiry
chore: update dependencies
常见类型：
| 类型 | 含义 |
|---|---|
| feat | 新功能 |
| fix | 修复 bug |
| docs | 文档修改 |
| style | 格式调整，不影响逻辑 |
| refactor | 重构，不新增功能也不修复 bug |
| test | 增加测试 |
| chore | 杂项，例如依赖、配置 |
对 AI 说的自然语言指令
你可以这样指挥 AI：
现在这版功能已经测试通过。
请先运行 git status 和 git diff，确认改动范围。
如果改动符合预期，请帮我 git add 并 commit。
commit message 要写清楚这次修改了什么。
不要 push。
更严格一点：
请只提交本次登录功能相关的文件。
不要提交 .env、node_modules、dist、build 等无关文件。
提交前先列出将要提交的文件清单，等我确认后再执行。
2. Push：上传到 GitHub
Push 是什么？
Push 是把本地 commit 上传到远程仓库。
白话理解：
把本机存档同步到云端。
Commit 和 Push 的区别
这是新手最容易混淆的地方。
commit = 本地存档
push = 上传存档到 GitHub
也就是说：
你 commit 了 10 次，如果没有 push，GitHub 上什么都看不到。
第一次推送本地项目到 GitHub
通常流程是：
git init
git add .
git commit -m "init: project setup"
git branch -M main
git remote add origin https://github.com/你的用户名/你的仓库.git
git push -u origin main
解释：
git init
初始化本地 Git 仓库。
git add .
把当前文件加入暂存区。
git commit -m "init: project setup"
创建第一次提交。
git branch -M main
把当前分支命名为 main。
git remote add origin https://github.com/你的用户名/你的仓库.git
把本地仓库和 GitHub 仓库关联起来。
git push -u origin main
第一次推送，并记住默认推送目标。
对 AI 说的自然语言指令
帮我把当前本地仓库关联到 GitHub 远程仓库。
远程地址是：https://github.com/你的用户名/你的仓库.git
请先检查 git remote -v。
如果还没有 origin，请添加 origin。
然后推送到 main 分支。
五、Vibe Coder 必须优先学会的安全规则：.gitignore
1. 为什么 .gitignore 极其重要？
如果你的项目里有：
OpenAI API Key
Stripe Secret Key
数据库密码
云服务 Access Key
JWT Secret
第三方服务 Token
一旦不小心 push 到 GitHub 公开仓库，可能会造成严重后果：
- API Key 被扫描器自动抓走。
- 被盗刷。
- 数据库被连接。
- 云服务资源被滥用。
- 产生真实金钱损失。
所以版本控制第一课不是 commit，而是：
不要把密钥提交到 Git 仓库。
2. .gitignore 是什么？
.gitignore 是一个配置文件。
它告诉 Git：
哪些文件不要追踪。
哪些文件不要提交。
例如：
.env
.env.local
node_modules/
dist/
build/
.DS_Store
*.log
3. 常见 .gitignore 示例
Node.js / 前端项目
node_modules/
dist/
build/
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.DS_Store
Python 项目
__pycache__/
*.py[cod]
.env
.venv/
venv/
env/
dist/
build/
*.log
.DS_Store
通用敏感文件
.env
*.pem
*.key
secrets.json
credentials.json
4. 重要提醒：.gitignore 不能忽略已经提交过的文件
如果 .env 已经被 commit 过了，后面再写进 .gitignore 是不够的。
因为 Git 已经开始追踪它了。
这时需要：
- 立刻更换泄露的密钥。
- 从 Git 历史中清理该文件。
- 通知协作者。
- 必要时重新创建仓库。
只删除最新一次提交里的文件，不等于从历史中删除。
5. 如果密钥已经提交到 GitHub，怎么办？
正确顺序：
第一步：立即作废并重新生成密钥。
第二步：从代码和历史中清理密钥文件。
第三步：检查是否还有别的地方泄露。
第四步：通知协作者。
不要只是：
删除文件，再 commit 一次。
因为历史里仍然有。
6. 对 AI 说的安全指令
请检查当前项目是否存在敏感文件。
重点检查 .env、API Key、Token、密码、私钥、credentials、secrets。
确保这些文件已经加入 .gitignore。
如果它们已经被 Git 追踪，请告诉我，不要直接提交。
不要把这些文件 commit 或 push 到远程仓库。
六、几个常见术语：local、remote、origin、main
1. local：本地
指你自己电脑上的代码和 Git 仓库。
local = 你的电脑
2. remote：远程
指远程服务器上的仓库，通常在 GitHub。
remote = 云端仓库
3. origin：远程仓库的默认别名
当你 clone 一个 GitHub 仓库时，Git 通常会把远程仓库命名为：
origin
你可以理解为：
origin 就是“默认的那个 GitHub 地址”
查看远程仓库：
git remote -v
可能看到：
origin https://github.com/yourname/project.git (fetch)
origin https://github.com/yourname/project.git (push)
4. main：主分支
main 通常是项目的正式稳定分支。
以前很多项目默认分支叫：
master
现在更常见的是：
main
你可以理解为：
main = 正式版代码
5. “push 到 origin main”是什么意思？
这句话的意思是：
把本地 main 分支的提交，推送到名为 origin 的远程仓库里的 main 分支。
命令：
git push origin main
如果是第一次推送：
git push -u origin main
七、团队协作基础：Clone 与 Pull
1. Clone：完整复制一个项目
如果你想参与一个已有项目，不要只是 Download ZIP。
Download ZIP 的问题是：
只有文件，没有 Git 历史。
你拿不到：
- 提交记录。
- 分支信息。
- 远程仓库关联。
- 版本历史。
- 合并记录。
正确方式是 clone：
git clone https://github.com/用户名/仓库名.git
白话理解：
把整盒带历史记录的棋盘完整复制到你电脑上。
Clone 之后你会得到什么？
你会得到：
完整代码
完整提交历史
远程仓库关联
默认分支
你可以查看历史：
git log
查看远程仓库：
git remote -v
注意：Clone 不等于拥有写权限
Clone 只是把仓库复制到本地。
你能不能 push，取决于：
你是否被仓库管理员授予写权限。
如果没有权限，你可以：
- Fork 项目。
- Clone 自己的 Fork。
- 修改后提交 PR。
2. Pull：拉取最新进度
当队友把代码 push 到 GitHub 后，你本地不会自动同步。
你需要执行：
git pull
白话理解：
从云端下载最新进度。
Pull 的本质
默认情况下：
git pull = git fetch + git merge
也就是：
- 先从远程下载最新提交。
- 再合并到你当前分支。
对 AI 说的自然语言指令
开始开发前，请先帮我检查当前分支。
如果我在 main 分支，请先 git pull，确保本地是最新进度。
然后再从最新 main 创建新的功能分支。
八、团队协作四步循环
对于新手，记住这个循环就够了：
1. clone：第一次加入项目。
2. pull：开始工作前，先拉取最新代码。
3. commit：自己改好后，本地存档。
4. push：把本地存档推送到远程。
更完整的工程流程是：
pull main
↓
create branch
↓
modify code
↓
test
↓
commit
↓
push branch
↓
open PR
↓
code review
↓
merge
↓
pull main again
九、Branch：AI 编程时代最重要的防爆机制
1. 为什么需要 Branch？
假设你正在开发一个新功能。
AI 可能需要：
- 反复修改。
- 尝试方案。
- 重构代码。
- 删除文件。
- 替换依赖。
- 修改多个模块。
如果直接在 main 上改，会出现一个问题：
在功能完成之前，main 可能一直是半坏状态。
这非常危险。
2. Branch 是什么？
Branch 是分支。
你可以理解为：
平行时空实验沙盒。
在分支上，AI 可以随便试错。
只要不合并，主线就不会受影响。
main：正式稳定版
feature/login：登录功能实验分支
fix/payment：支付 bug 修复分支
3. 分支的核心价值
隔离风险。
具体好处：
- 不污染 main。
- 可以同时开发多个功能。
- 方便代码审查。
- 方便回滚。
- 方便多人或多 AI 并行工作。
- 实验失败可以直接删除分支。
4. 创建并切换分支
推荐使用较新的 Git 命令：
git switch -c feat/coupon-claim
它表示：
创建并切换到 feat/coupon-claim 分支。
旧命令也可以：
git checkout -b feat/coupon-claim
查看当前分支：
git branch
当前分支前面会有 *。
5. 切换回 main
git switch main
或者旧命令：
git checkout main
6. 推送新分支到 GitHub
第一次推送新分支：
git push -u origin feat/coupon-claim
之后再推送：
git push
7. 分支命名建议
推荐格式：
feat/功能名
fix/问题名
refactor/模块名
docs/文档名
chore/杂项名
示例：
feat/user-login
feat/coupon-claim
fix/payment-timeout
refactor/coupon-service
docs/update-readme
8. 对 AI 说的分支指令
现在准备开发优惠券领取功能。
请先确认当前是否在 main 分支。
如果是，请先 git pull。
然后从最新 main 创建并切换到 feat/coupon-claim 分支。
之后所有改动都只提交到这条分支。
不要修改 main。
不要直接合并到 main。
十、PR 与 Merge：把分支成果合并回主线
1. PR 是什么？
PR 全称：
Pull Request
在 GitLab 里通常叫：
Merge Request
PR 不是 Git 本身的命令，而是 GitHub 等平台提供的协作机制。
它的作用是：
告诉团队：我这个分支改好了，请审查，看看能不能合并。
2. PR 的标准流程
1. 从 main 创建分支。
2. 在分支上开发。
3. 提交 commit。
4. push 分支到 GitHub。
5. 在 GitHub 上创建 PR。
6. 邀请别人 review。
7. 根据反馈修改。
8. 审查通过后 merge。
3. PR 描述应该写什么？
一个好的 PR 应该包含：
1. 这次做了什么。
2. 为什么这么做。
3. 改了哪些文件。
4. 如何测试。
5. 是否有风险。
6. 是否涉及数据库、环境变量、依赖变化。
模板：
## 功能说明
实现用户领取优惠券功能。
## 修改内容
- 新增优惠券领取接口。
- 增加用户限领校验。
- 增加优惠券过期校验。
- 增加相关单元测试。
## 测试方式
1. 使用未领取过的用户调用领取接口。
2. 验证返回成功。
3. 验证数据库生成用户优惠券记录。
4. 验证重复领取返回错误。
5. 验证过期优惠券无法领取。
## 风险
- 涉及数据库写入。
- 需要注意并发领取时的库存问题。
## 截图 / 日志
如有必要，附上测试截图或日志。
4. 对 AI 说的 PR 指令
帮我把当前分支推送到 GitHub。
然后准备一个 PR 描述。
PR 标题要简洁说明本次功能。
PR 内容需要包括：
1. 本次做了什么。
2. 修改了哪些文件。
3. 如何测试。
4. 是否有风险。
不要直接 merge。
5. Merge 是什么？
Merge 是把分支代码合并回主线。
例如：
feat/coupon-claim → main
合并之后，新功能才正式进入主线。
6. 常见 Merge 方式
GitHub 上常见有三种合并方式。
Merge commit
保留完整分支历史，并生成一个合并提交。
适合：
想保留完整开发过程。
Squash and merge
把分支上的多个 commit 压缩成一个 commit。
适合：
分支里有很多零碎提交，希望主线历史更干净。
例如：
fix
fix again
update
wip
test
最终压缩成：
feat: add coupon claim
Rebase and merge
让提交历史变成一条直线。
适合：
希望历史线性、清晰。
但新手使用时要谨慎，尤其是公共分支。
7. 新手最容易踩的坑：网页 Merge 后本地没同步
在 GitHub 网页上点击 Merge 后，发生的是：
远程 main 更新了。
但是你电脑上的 main 不会自动同步。
你必须手动拉取：
git switch main
git pull
否则下次你从本地 main 开新分支时，可能基于旧代码开发。
8. Merge 后的标准动作
git switch main
git pull
然后再开新分支：
git switch -c feat/next-feature
9. 对 AI 说的自然语言指令
这个 PR 已经在 GitHub 上合并了。
请帮我切回本地 main 分支。
然后执行 git pull，确保本地 main 是最新版本。
之后再从最新 main 创建新的功能分支。
十一、Worktree：多 AI 并行开发的黑科技
1. Branch 的局限
Branch 虽然能隔离风险，但有一个现实问题：
同一个项目文件夹，同一时间通常只能显示一个分支。
如果你有两个 AI Agent：
Agent A 开发数据库功能。
Agent B 开发 UI 功能。
它们如果在同一个文件夹里工作，就可能互相干扰。
比如：
- A 刚切到数据库分支。
- B 又切到 UI 分支。
- 文件状态混乱。
- AI 看到的内容不一致。
- 提交范围出错。
2. Worktree 是什么？
Worktree 可以让一个 Git 仓库同时拥有多个工作目录。
白话理解：
同一个 Git 记忆库，
额外长出第二张、第三张实体办公桌。
每张桌子可以打开不同分支。
但它们共享同一个 Git 历史。
3. Worktree 的典型场景
假设你有两个任务：
任务 A：数据库功能
任务 B：UI 功能
你可以创建两个独立目录：
project/
project-db/
project-ui/
其中：
project/ 主工作目录
project-db/ 数据库分支工作目录
project-ui/ UI 分支工作目录
然后：
Agent A 在 project-db/ 里开发 feat/db
Agent B 在 project-ui/ 里开发 feat/ui
两者互不干扰。
4. 创建 Worktree
假设当前主项目在：
project/
你想新增一个数据库工作目录：
git worktree add ../project-db -b feat/db
意思是：
在上级目录创建 project-db 文件夹。
同时创建并切换到 feat/db 分支。
再创建一个 UI 工作目录：
git worktree add ../project-ui -b feat/ui
5. 查看 Worktree
git worktree list
可能看到：
/project abc1234 [main]
/project-db def5678 [feat/db]
/project-ui ghi9012 [feat/ui]
6. 删除 Worktree
如果某个 worktree 不用了：
git worktree remove ../project-db
如果还有未提交修改，Git 会阻止删除。
确认不需要后可以强制删除，但要谨慎：
git worktree remove --force ../project-db
7. Worktree 注意事项
同一个分支通常不能同时被多个 worktree 检出
例如：
worktree A 已经 checkout main
worktree B 通常不能再 checkout main
这是为了避免两个目录同时修改同一个分支状态。
Worktree 不是复制仓库
Worktree 不是 git clone。
它共享同一个 .git 数据。
优点：
省空间。
历史一致。
分支一致。
提交互通。
多 AI 并行时，任务边界要清楚
建议：
一个 Agent 一个 worktree。
一个 worktree 一个功能分支。
一个功能分支对应一个明确任务。
不要让多个 Agent 同时改同一个 worktree。
8. 对 AI 说的 Worktree 指令
我需要并行开发两个功能。
请基于当前 main 创建两个 worktree：
1. ../project-db，分支 feat/db，用于数据库功能。
2. ../project-ui，分支 feat/ui，用于 UI 功能。
创建前先确认当前 main 是最新状态。
不要修改 main。
每个 worktree 的改动只提交到对应分支。
十二、Conflict：冲突是什么，怎么处理？
1. 为什么会发生 Conflict？
当两个分支修改了同一处代码，Git 不知道该保留哪个版本，就会产生冲突。
例如：
A 把标题改成：
const title = "记账工具";
B 把同一行改成：
const title = "个人财务助手";
合并时 Git 会懵：
这一行到底听谁的？
2. 冲突长什么样？
冲突文件里可能出现：
<<<<<<< HEAD
const title = "记账工具";
=======
const title = "个人财务助手";
>>>>>>> feat/ui
含义：
<<<<<<< HEAD
当前分支的内容。
=======
分隔线。
>>>>>>> feat/ui
要合并进来的另一个分支的内容。
3. 解决冲突的本质
解决冲突不是单纯选 A 或选 B。
而是根据产品需求决定：
最终代码应该是什么。
可能有三种结果：
方案一：保留一边
例如以 A 为准：
const title = "记账工具";
方案二：两边都保留
例如两边只是新增不同内容：
const categories = ["餐饮", "交通", "理财"];
方案三：重新整合
例如两边逻辑都有价值，但需要重新设计：
const basicCategories = ["餐饮", "交通"];
const advancedCategories = ["理财"];
4. 解决冲突的标准流程
git status
查看哪些文件冲突。
然后打开冲突文件，手动或让 AI 修改成最终正确版本。
解决后：
git add 冲突文件
git commit
如果是在 rebase 过程中：
git add 冲突文件
git rebase --continue
5. Vibe Coder 在冲突中的职责
你不需要亲自逐行改代码。
但你必须给 AI 明确的产品决策。
错误说法：
你帮我解决冲突。
这样 AI 可能乱猜。
正确说法：
帮我解决这个 conflict。
分类列表逻辑以 main 为主。
但是我新增的“理财”分类要保留，并移动到进阶选单里。
解决后运行测试。
不要删除已有功能。
6. 对 AI 说的冲突处理指令
当前 merge 出现 conflict。
请先运行 git status，列出冲突文件。
然后逐个解释冲突原因。
不要直接删除任何一边的逻辑。
产品决策如下：
1. 用户列表逻辑以 main 为准。
2. 我新增的理财分类要保留。
3. 理财分类移动到进阶选单。
4. 保持原有 UI 样式不变。
解决后请运行测试。
如果没有测试，请告诉我需要手动验证哪些页面。
十三、AI 把代码改坏了，怎么救？
这是 AI 编程时代最常见的问题。
别慌，先判断当前处于哪种状态。
情况一：AI 改了文件，但还没有 commit
这是最幸运的情况。
你可以恢复到上一次提交的状态。
1. 查看改动
git status
git diff
2. 恢复单个文件
git restore 文件名
例如：
git restore src/app.js
这会把 src/app.js 恢复到最近一次提交的状态。
3. 恢复所有文件
谨慎使用：
git restore .
这会把当前目录下的改动都恢复掉。
注意：
未提交的修改可能会永久丢失。
4. 如果文件已经 add 到暂存区
先取消暂存：
git restore --staged 文件名
再恢复文件：
git restore 文件名
5. 对 AI 说的指令
刚刚这次修改我不要了。
请先运行 git status 和 git diff。
如果这些改动还没有 commit，请帮我把它们恢复到上一次正常版本。
恢复前请先列出将被丢弃的文件。
不要删除未追踪的新文件，除非我明确确认。
情况二：已经 commit，但还没有 push
这时可以用 revert 安全撤销。
1. 查看提交历史
git log --oneline
你会看到类似：
a1b2c3d feat: add coupon claim
e4f5g6h fix: login redirect
2. 使用 revert 撤销某个 commit
git revert a1b2c3d
它不会删除历史，而是新增一个反向提交。
白话理解：
做一次相反操作，把之前的改动抵消掉。
3. 为什么推荐 revert？
因为 revert 保留历史记录。
它对协作更安全。
4. 对 AI 说的指令
我刚刚提交了一个错误 commit。
请先运行 git log --oneline，帮我找到最近一次错误提交。
然后用 git revert 撤销它。
不要使用 git reset --hard。
不要改写已经推送到远程的历史。
情况三：已经 push 到 GitHub
这时更推荐使用：
git revert
不推荐新手使用：
git reset --hard
git push --force
因为强制推送会改写远程历史，可能影响队友。
对 AI 说的安全指令
这个错误 commit 已经 push 到远程了。
请使用 git revert 生成一个反向提交来修复。
不要使用 force push。
不要改写远程历史。
完成后告诉我需要 push 哪些 commit。
情况四：需要彻底重置本地分支
如果你非常确定只想本地回退，可以使用：
git reset --hard 提交号
例如：
git reset --hard a1b2c3d
但这很危险。
它会移动分支指针，并可能丢弃改动。
新手谨慎使用。
尤其不要随便：
git reset --hard HEAD
git push --force
救急决策表
| 情况 | 推荐方式 | 风险 |
|---|---|---|
| 改了文件，还没 add / commit | git restore |
会丢弃未保存修改 |
| 已 add，还没 commit | git restore --staged + git restore |
会丢弃未保存修改 |
| 已 commit，没 push | git revert 或谨慎 reset |
revert 更安全 |
| 已 push 到远程 | git revert |
安全，保留历史 |
| 公共分支强制回退 | 不推荐 | 会影响协作者 |
| 密钥泄露 | 立即轮换密钥 + 清理历史 | 只删最新提交不够 |
十四、AI 编程时代的 Git 纪律
使用 AI 写代码时，版本控制不只是工具，更是安全边界。
建议建立以下纪律。
1. 不要让 AI 随意改 main
错误做法：
直接在 main 上让 AI 大改。
正确做法：
先从 main 创建功能分支。
所有实验都在分支里进行。
2. 每个小阶段都 commit
AI 可能一次改很多文件。
如果中间没有存档，一旦改坏，很难回退。
建议：
每完成一个可验证的小目标，就 commit 一次。
3. 提交前让 AI 检查改动
提交前先 git status 和 git diff。
避免把无关文件、临时文件、密钥文件提交进去。
4. 不要让 AI 自动 push 到 main
建议：
push 到功能分支可以。
merge 到 main 必须人工确认。
5. 禁止 AI 随便执行危险命令
以下命令需要特别谨慎：
git reset --hard
git clean -fd
git push --force
git checkout .
git restore .
git rebase
git filter-repo
可以给 AI 设置规则：
未经我明确确认，禁止执行：
git reset --hard
git clean -fd
git push --force
git rebase
git filter-repo
6. 多 Agent 并行必须隔离
推荐：
一个 Agent
一个 worktree
一个 branch
一个任务
不要让多个 Agent 同时操作同一个目录。
十五、给 Cursor / Claude Code 的项目规则模板
你可以在项目规则或系统提示中加入类似内容：
你是一名工程助手，必须遵守以下 Git 安全规则：
1. 修改代码前，先运行 git status，确认当前分支和工作区状态。
2. 未经确认，不要切换分支。
3. 未经确认，不要执行 git push。
4. 绝对禁止执行 git push --force。
5. 绝对禁止执行 git reset --hard，除非我明确要求。
6. 绝对禁止执行 git clean -fd，除非我明确要求。
7. 提交前必须运行 git diff，并列出改动文件。
8. 不要提交 .env、密钥、Token、密码、node_modules、dist、build 等文件。
9. 每个任务只提交与任务相关的改动。
10. commit message 使用 Conventional Commits 格式。
11. 开发新功能前，先从最新 main 创建功能分支。
12. 不要直接修改 main。
13. 不要自动合并 PR。
14. 如果出现 conflict，先列出冲突文件和冲突原因，等待我的产品决策。
十六、完整实战流程：从 0 到 PR
下面演示一个完整流程。
假设你要开发：
用户优惠券领取功能
第一步：确认当前状态
git status
对 AI 说：
请先运行 git status。
告诉我当前在哪个分支。
是否有未提交修改。
是否干净。
第二步：同步最新 main
git switch main
git pull
对 AI 说：
请切回 main 分支。
然后执行 git pull。
确保本地 main 是最新状态。
第三步：创建功能分支
git switch -c feat/coupon-claim
对 AI 说：
请从最新 main 创建并切换到 feat/coupon-claim 分支。
之后所有修改都只提交到这条分支。
第四步：让 AI 开发功能
请实现用户领取未过期优惠券功能。
要求：
1. 先写失败测试。
2. 再写最小实现。
3. 不要实现优惠券核销。
4. 不要修改无关文件。
5. 每完成一个小步骤就停下来汇报。
第五步：检查改动
git status
git diff
对 AI 说：
提交前请先运行 git status 和 git diff。
列出所有改动文件。
确认没有 .env、密钥、node_modules、dist、build 等文件。
第六步：提交
git add .
git commit -m "feat: add coupon claim endpoint"
对 AI 说：
如果改动符合预期，请帮我提交。
commit message 使用 feat: add coupon claim endpoint。
不要 push。
第七步：推送分支
git push -u origin feat/coupon-claim
对 AI 说：
请把 feat/coupon-claim 分支推送到 GitHub。
不要合并到 main。
第八步：创建 PR
对 AI 说：
帮我准备一个 PR 描述。
标题：feat: add coupon claim endpoint
内容包含：
1. 功能说明。
2. 修改文件。
3. 测试方式。
4. 风险点。
不要直接 merge。
第九步：审查通过后合并
在 GitHub 上选择合适的合并方式：
Merge commit
Squash and merge
Rebase and merge
新手推荐：
Squash and merge
主线历史会更干净。
第十步：合并后同步本地 main
git switch main
git pull
对 AI 说：
PR 已经合并。
请切回 main。
执行 git pull。
确认本地 main 已经同步远程最新版本。
十七、常见问题 FAQ
Q1：我 commit 了，GitHub 上为什么看不到？
因为 commit 只是本地存档。
你需要：
git push
Q2：Download ZIP 和 Clone 有什么区别？
Download ZIP：
只有文件，没有 Git 历史。
Clone：
有文件，也有完整 Git 历史和远程关联。
Q3：Pull 和 Clone 有什么区别？
Clone 是第一次完整复制项目。
Pull 是后续同步远程最新改动。
第一次用 clone。
之后用 pull。
Q4：Branch 和 Worktree 有什么区别？
Branch 是版本线。
Worktree 是工作目录。
Branch：平行时空。
Worktree：实体办公桌。
一个 branch 可以在一个 worktree 中被打开。
多个 worktree 可以同时服务不同 branch。
Q5：PR 和 Merge 有什么区别？
PR 是提案。
Merge 是合并动作。
PR：请大家审查我的改动。
Merge：审查通过，正式合并。
Q6：Conflict 一定会发生吗？
不一定。
只有当不同分支修改了同一处代码，并且 Git 无法自动判断时，才会冲突。
Q7：AI 能帮我解决冲突吗？
可以辅助。
但你必须给 AI 明确决策。
例如：
以 main 的逻辑为主。
保留我新增的理财分类。
把理财分类移动到进阶选单。
不要只说：
你帮我解决。
Q8：API Key 不小心提交了怎么办？
第一优先级：
立即作废并重新生成密钥。
然后清理历史。
不要只删除最新文件。
Q9：可以一直不学命令，只让 AI 操作吗？
可以开始这样用。
但你至少要理解：
commit
push
pull
branch
merge
conflict
restore
revert
.gitignore
否则 AI 问你：
是否要 reset？
是否要 force push？
是否要丢弃未提交修改？
你可能做出错误决策。
Q10：Vibe Coder 最应该记住哪几句话？
记住这几句就够了：
开发前先 pull。
新功能先开 branch。
改好先 commit。
上传用 push。
合并走 PR。
合并后再 pull。
密钥永远不进仓库。
危险命令必须人工确认。
十八、核心总结表
| 概念 / 指令 | 白话比喻 | 解决的问题 |
|---|---|---|
| Git | 本机版本追踪器 | 记录每次改动，防止代码改坏后无法回退 |
| GitHub | 云端代码仓库 | 备份代码、团队协作、代码审查 |
git init |
开始追踪项目 | 把普通文件夹变成 Git 仓库 |
| Working Directory | 办公桌 | 你正在编辑的文件 |
| Staging Area | 打包纸箱 | 准备提交的改动集合 |
git add |
把文件放进纸箱 | 将改动加入暂存区 |
git commit |
手动游戏存档 | 在本地建立安全检查点 |
git push |
上传存档到云端 | 把本地提交同步到 GitHub |
git pull |
下载最新存档 | 获取远程最新代码 |
git clone |
复制整盒带历史的棋盘 | 第一次完整加入项目 |
local |
你的电脑 | 本地仓库和工作区 |
remote |
云端地址 | 远程仓库 |
origin |
默认远程仓库别名 | 通常指向 GitHub 仓库 |
main |
正式稳定版 | 项目主线分支 |
.gitignore |
禁止进入的密室门牌 | 防止密钥、密码、构建产物被提交 |
branch |
平行时空沙盒 | 隔离新功能开发风险 |
worktree |
多一张实体办公桌 | 多 AI / 多任务并行开发 |
| PR | 修改提案 | 代码审查与合并流程 |
| Merge | 合并分支 | 将功能并入主线 |
| Conflict | 两个版本打架 | 需要人工或 AI 根据产品决策解决 |
restore |
一键读档 | 恢复未提交的修改 |
revert |
倒带撤销 | 安全撤销已经提交的改动 |
reset |
强制回退 | 本地回退历史，风险较高 |
十九、最终建议：Vibe Coder 不需要背命令，但必须会做决策
你不需要一开始就记住所有 Git 命令。
但你必须知道：
现在该不该存档？
现在该不该上传？
现在该不该开分支？
现在该不该合并？
这个改动能不能回退？
这个密钥能不能提交？
这个冲突应该保留哪边逻辑？
这个危险命令该不该执行？
AI 可以帮你执行命令。
但产品决策和安全边界必须由你掌握。
真正成熟的 AI 编程流程是：
先理解概念。
再指挥 AI。
用小步提交保护代码。
用分支隔离风险。
用 PR 保证审查。
用 .gitignore 保护密钥。
用 restore / revert 处理事故。
当你能理解 AI 弹出的每一个 Git 术语时，你就不再是被 AI 拖着走的 Vibe Coder，而是能真正掌控项目的工程指挥者。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
1
0- 0
已为社区贡献5条内容
所有评论(0)