AI coding学习——git管理

AI Coding 场景下的 Git 管理

随着AI编程越来越火，个人也是尝试接触学习，但是用着的时候发现让AI改动代码有时候会把原有功能给改坏，故学习了一下怎么用git做项目管理。

核心原则：让 AI 改代码前，先把当前稳定状态保存成 Git commit；让 AI 在独立分支上改；改完后测试、人工验证、再提交；确认没问题后再合并回 main。

1. 为什么 AI Coding 必须配合 Git

使用 AI 改项目时，最常见的风险是：

• AI 修改范围过大，动了无关文件。
• AI 修一个功能，顺手破坏了已有功能。
• AI 改完后你不知道它到底改了哪些地方。
• 改坏后只能靠记忆手动恢复。

Git 的作用就是给项目建立“可回退的存档系统”：

• commit：一次正式存档。
• branch：一个独立开发空间。
• diff：查看 AI 到底改了什么。
• tag：给重要版本贴标签，比如 v1.0、v1.1。
• checkout / restore / reset：切换或回退版本。

Important

git add 不是保存版本，它只是把文件放进“暂存区”。真正能回退的安全存档点是 git commit。

2. Git 版本文件存在什么地方

Git 不会在项目里生成 version1/、version2/ 这样的目录。

它会在项目根目录生成一个隐藏目录：

.git/

项目结构大概是：

my-project/
  .git/
  src/
  package.json
  README.md

其中：

• .git/ 保存提交记录、分支、标签、历史版本和配置。
• 当前看到的 src/、package.json 等文件，是当前工作区。
• 切换分支或版本时，Git 会根据 .git/ 里的记录更新当前工作区文件。

Warning

不要手动删除或修改 .git/。删除 .git/ 后，项目文件还在，但 Git 历史、分支和版本记录会丢失。

3. 第一次给项目接入 Git

进入项目目录：

cd 你的项目目录

初始化 Git：

git init

查看状态：

git status

创建 .gitignore，避免提交依赖、构建产物、环境变量和编辑器缓存。

前端 / Node 项目常见 .gitignore：

node_modules/
dist/
build/
.env
.env.local
.DS_Store
.vscode/
.idea/

Python 项目常见 .gitignore：

__pycache__/
*.pyc
.venv/
venv/
.env
.ipynb_checkpoints/
.DS_Store
.vscode/
.idea/

做第一次完整存档：

git add .
git commit -m "chore: initial project snapshot"

从这一步开始，项目就有了第一个可回退的安全版本。

4. 让 AI 改功能前的标准流程

每次改功能前，先确认当前项目是否已经保存。

git status

如果当前是稳定状态，但还有未提交改动，先存档：

git add .
git commit -m "chore: save stable state before AI changes"

然后从稳定分支创建功能分支：

git checkout main
git checkout -b feature/功能名

让 AI 在这个功能分支上修改代码。

Tip

main 分支只放稳定版本。每次功能开发、实验、修复都放到单独分支里。

5. AI 改完后的验证流程

AI 改完后，先看它改了什么：

git status
git diff

如果是前端 / Node 项目，常见验证命令是：

npm test
npm run build
npm run dev

三个命令的含义不同：

• npm test：运行自动化测试，用测试代码检查主代码。
• npm run build：构建生产版本，检查语法、类型、依赖和打包问题。
• npm run dev：启动开发服务器，方便人工打开浏览器验证功能。

Note

不是所有项目都有这三个命令。具体要看 package.json 里的 scripts 配置。

查看 package.json：

cat package.json

Windows PowerShell：

Get-Content package.json

人工验证功能正常后，在功能分支提交：

git add .
git commit -m "feat: add xxx feature"

然后合并回 main：

git checkout main
git merge feature/功能名

合并后建议在 main 上再验证一次：

npm test
npm run build

6. 完整安全工作流

main 当前稳定
→ 如有改动，先 commit 保存
→ 创建 feature/功能名 分支
→ AI 在功能分支上改代码
→ 查看 git diff
→ 自动测试
→ 构建检查
→ 启动项目
→ 人工验证
→ 在功能分支 commit
→ 合并回 main
→ main 再测试 / 构建一次

对应命令：

git status
git add .
git commit -m "chore: save stable state before AI changes"

git checkout main
git checkout -b feature/功能名

# 让 AI 修改代码

git status
git diff
npm test
npm run build
npm run dev

git add .
git commit -m "feat: add xxx feature"

git checkout main
git merge feature/功能名

npm test
npm run build

Warning

不要在功能分支没有 commit 的情况下直接切回 main 合并。先在功能分支提交，再合并。

7. 多个思路怎么保留多个版本

如果想先试一个思路，再试另一个思路，推荐使用多个实验分支。

例如尝试登录功能的两个方案：

git checkout main
git checkout -b experiment/login-plan-a

让 AI 实现方案 A，验证后提交：

git add .
git commit -m "experiment: try login plan A"

再从 main 创建方案 B：

git checkout main
git checkout -b experiment/login-plan-b

让 AI 实现方案 B，验证后提交：

git add .
git commit -m "experiment: try login plan B"

现在你有三个互不影响的版本：

main
experiment/login-plan-a
experiment/login-plan-b

切换查看方案 A：

git checkout experiment/login-plan-a

切换查看方案 B：

git checkout experiment/login-plan-b

最终决定采用方案 B：

git checkout main
git merge experiment/login-plan-b

如果方案 A 不要了：

git branch -D experiment/login-plan-a

Tip

一个思路对应一个 experiment/xxx 分支。最后选择最满意的分支合并回 main。

8. 用 tag 保存 v1.0 / v1.1

如果你想用“版本号”的方式管理项目，可以使用 Git tag。

关系如下：

commit = 一次保存
tag = 给某次 commit 起版本名

例如，当前稳定版本保存为 v1.0：

git add .
git commit -m "chore: release v1.0 baseline"
git tag v1.0

增加功能：

git checkout -b feature/xxx

功能开发完成后：

git add .
git commit -m "feat: add xxx feature"
git checkout main
git merge feature/xxx
git tag v1.1

查看所有标签：

git tag

查看 v1.0 状态：

git checkout v1.0

Warning

直接 git checkout v1.0 只是查看旧版本，不建议在这个状态继续开发。

更安全的恢复方式是从 v1.0 创建新分支：

git checkout -b restore/v1.0 v1.0

确认没问题后，再决定是否让 main 回退。

如果非常确定要把 main 强制回到 v1.0：

git checkout main
git reset --hard v1.0

Danger

git reset --hard 会让当前分支回到指定版本，并丢弃之后的工作区状态。除非非常确定，否则优先使用 restore/v1.0 这种恢复分支。

9. 改坏了怎么回退

9.1 AI 改了，但还没有 commit

查看改动：

git status
git diff

撤销所有已跟踪文件的未提交改动：

git restore .

查看将要删除的新增文件：

git clean -fdn

确认删除新增文件：

git clean -fd

9.2 AI 改了，已经 commit，但还没合并 main

直接回到 main，删除这个功能分支：

git checkout main
git branch -D feature/功能名

9.3 AI 改了，已经合并 main，想回到 v1.0

优先创建恢复分支：

git checkout -b restore/v1.0 v1.0

确认恢复分支没问题后，再决定是否让 main 回退。

10. 常用分支命名

feature/login-page        新功能
bugfix/login-error        修复 bug
hotfix/critical-login     紧急修复
refactor/auth-service     重构
experiment/search-ui-a    实验方案
restore/v1.0              恢复旧版本
docs/git-workflow         文档

11. 常用 commit message

git commit -m "feat: add user login"
git commit -m "fix: resolve login redirect bug"
git commit -m "refactor: simplify auth service"
git commit -m "style: update homepage layout"
git commit -m "docs: update setup guide"
git commit -m "test: add login tests"
git commit -m "chore: save current work"
git commit -m "experiment: try search UI plan A"

推荐前缀：

• feat：新增功能。
• fix：修复问题。
• refactor：重构。
• style：样式或格式调整。
• docs：文档。
• test：测试。
• chore：维护性工作。
• experiment：实验性方案。

12. 给 AI 的通用 Git 管理提示词

12.1 开发新功能

请用 Git 安全管理本次开发：

1. 开始前检查 git status，告诉我当前分支和工作区状态。
2. 如果当前目录还不是 Git 仓库，请先 git init，并创建初始提交。
3. 如果有未提交改动，不要覆盖，先告诉我有哪些改动，等我确认。
4. 如果工作区干净，请从 main 创建本次开发分支，分支名使用 feature/简短功能名。
5. 修改代码时只改和本需求相关的文件，不做无关重构。
6. 修改完成后运行项目已有测试、构建或启动检查。
7. 最后展示当前分支、修改文件、每个文件主要改了什么、测试或构建结果、git diff 摘要。
8. 验证通过后创建一次 commit，commit message 使用 Conventional Commits 格式。
9. 不要自动合并到 main。
10. 不要执行 git reset --hard、git clean -fd、强制 push、删除分支等危险操作，除非我明确确认。

12.2 更保守：先计划再修改

请先不要修改代码。

先检查 Git 状态和项目结构，然后给我一个开发计划，包括：

1. 当前分支和工作区状态。
2. 预计修改哪些文件。
3. 每个文件为什么需要修改。
4. 如何验证。
5. 可能风险点。

等我确认后，再创建 feature/功能名 分支并开始修改。修改完成后只提交到该分支，不要合并 main。

12.3 同时实验两个方案

我想对这个功能尝试两个方案，请分别用两个 Git 分支实现：

- experiment/功能名-plan-a：实现方案 A
- experiment/功能名-plan-b：实现方案 B

要求：

1. 两个分支都从 main 创建。
2. 每个分支只包含对应方案的改动。
3. 每个方案完成后都运行测试或构建。
4. 每个分支各自提交一次 commit。
5. 不要自动合并到 main。
6. 最后对比两个方案的优缺点，并告诉我建议合并哪个分支。

12.4 保存为 v1.0，再开发 v1.1

请先用 Git 把当前项目保存为 v1.0：

1. 检查 git status。
2. 如果当前还不是 Git 仓库，请初始化 Git。
3. 将当前稳定状态提交为 commit，commit message 为 chore: release v1.0 baseline。
4. 创建 Git tag：v1.0。
5. 然后从 main 创建 feature/功能名 分支。
6. 在该分支上实现功能。
7. 修改完成后运行测试、构建和启动检查。
8. 如果验证通过，将功能分支提交并合并回 main。
9. 合并后创建 Git tag：v1.1。
10. 不要执行 reset --hard 或删除分支，除非我明确确认。

12.5 回退到 v1.0

我觉得 v1.1 改得不好，请帮我回到 v1.0。

要求：

1. 先不要直接 reset main。
2. 先检查当前 git status、git log --oneline 和 git tag。
3. 从 tag v1.0 创建一个新分支 restore/v1.0。
4. 切换到 restore/v1.0 后运行测试或启动检查。
5. 告诉我当前状态是否已经回到 v1.0。
6. 等我确认后，再决定是否让 main 回退到 v1.0。

12.6 审查 AI 的改动

请基于当前 git diff 做一次代码审查。重点检查：

1. 是否有无关文件被修改。
2. 是否破坏已有功能。
3. 是否有明显 bug。
4. 是否有安全风险。
5. 是否缺少测试。
6. 是否符合项目现有代码风格。

请先列风险和问题，再给出是否建议提交。

13. 命令速查

场景	命令
查看状态	git status
查看改动	git diff
暂存全部改动	git add .
提交版本	git commit -m "说明"
查看历史	git log --oneline
新建并切换分支	git checkout -b feature/xxx
切换分支	git checkout main
合并分支	git merge feature/xxx
查看分支	git branch
删除已合并分支	git branch -d feature/xxx
强制删除分支	git branch -D feature/xxx
创建标签	git tag v1.0
查看标签	git tag
查看某个版本	git checkout v1.0
从旧版本创建恢复分支	git checkout -b restore/v1.0 v1.0
撤销未提交改动	git restore .
预览将删除的新增文件	git clean -fdn
删除新增未跟踪文件	git clean -fd

14. 最终记忆口诀

改前先 commit，开发开分支；改后看 diff，测试再提交；满意合 main，不满意删分支；重要版本打 tag。