企业官网建设流程全解析

AI 辅助编程时代，Git 工作流应该怎么调整

AI 编程工具这两年火得不行。Cursor、Claude Code、GitHub、Copilot，随便打开一个技术社区都能看到相关的讨论。这些工具确实好用——代码生成、Bug 修复、重构优化，以前半小时的活现在五分钟就可以搞定。

但有个问题，聊的人不多：

代码写得快了，版本管理跟上了吗？

我最近在系统学 Git，越学越觉得：Git 在 AI 编程时代不但没被削弱，反而更重要了。以前你手动写代码，每一行都是自己的意图，脑子里有完整的上下文。现在 AI帮你生成大片代码，一个问题就来了——你真的确定它改了哪些文件吗？改坏了你能回退吗？

这篇文章不讲 Git 基础命令怎么用，而是聊一个更实际的话题：AI 辅助编程场景下，Git工作流需要做哪些调整。 都是实操经验，每一条都对应具体的 Git 命令和场景。

一、第一条红线：Push 必须自己来

这是最重要的一条原则，放第一个说。

AI 编程工具的能力范围越来越大——读代码、写代码、改代码、跑测试，甚至能自己开分支、提交 commit。很多工具（比如 Claude Code）默认就有执行终端命令的能力。

这就带来一个问题：AI 能不能帮你 push？
我的答案：不能。Push 必须你自己来。

为什么？

AI 做本地操作是安全的——git add、git commit、创建分支、切分支，这些操作的影响范围只在你的电脑上。改错了可以撤回，commit 错了可以 reset。

但 git push 不一样。代码一旦推送到远程仓库，全队都看得见。AI 不知道你们团队的：

• 发布节奏（今天能不能发版？）
• 分支策略（这个分支允许直接 push 还是必须走 PR？）
• 代码审查状态（review 过了吗？CI 跑完了吗？）

更危险的是 git push --force。AI 可能会在不知情的情况下，用力推覆盖掉同事刚提交的代码。

实操建议：

如果你用 Claude Code 这类带终端权限的工具，直接把 git push 写进权限黑名单：

# 允许 AI 做本地 Git 操作allow:gitstatus,gitdiff,gitlog,gitadd,gitcommit# push 必须人工确认deny:gitpush

一句话总结：

AI 可以帮你写代码、改代码、提交代码，但"发布"这个按钮，只能你自己按。

二、每次让 AI 写代码前，先 Commit

AI 改代码有个特点：批量、多文件、一步到位。

你给它一个需求，它可能同时改5个文件、新增2个、删掉不相关的代码。这跟人工开发完全不同——人工是一个文件一个文件改，每一步都知道自己动了什么。

AI 改完之后，如果你觉得不满意，想回到改之前的状态，怎么办？手动一个个文件 Ctrl+Z？不现实。

所以一个简单的习惯能救你无数次：

“打开 AI 工具之前，先 commit。”

具体怎么做：

每次准备让 AI 动手改代码之前：

# 1. 看看当前有什么改动还没提交gitstatus# 2. 全部提交，保证工作区干净gitadd.gitcommit-m"保存现场：AI 改代码前"

然后放心把代码交给 AI。

AI 改坏了怎么办

# 一键回到 commit 之前的状态gitreset--hardHEAD

工作区瞬间还原，干干净净。

如果不想 commit

有时候改动还没到可以 commit 的程度，但又想让 AI 开始工作。这时候用 stash：

# 把当前改动暂存到"草稿箱"gitstash# AI 工作完了，把草稿箱的改动拿出来gitstash pop

为什么这件事在 AI 时代更重要

人工写代码时，你改了什么心里有数。AI改代码时，你只是给了需求，具体动了哪些文件你并不完全清楚。commit 就是你给 AI 准备的"撤销键"——不管它改了多少、改了什么，你都能一秒回退。

“Commit 是你给 AI 的撤销键。你越信任 AI，越要先把撤销键攥在手里。”

三、学会看 Diff，别闭眼点 Accept

用 AI 编程工具久了，很容易养成一个习惯：AI生成一堆代码，扫一眼差不多，点"全部接受"。

这个习惯很危险。AI 生成的代码常见三种坑：

1. 删掉重要内容 — 你的注释、TODO、调试日志，AI 可能觉得“没用”直接删了
2. 偷偷改不相干的文件 — 你让 AI 修一个 Bug，它顺便“优化”了另外三个文件
3. 看起来对但逻辑有坑 — 代码能跑，边界条件没考虑全，测试一跑就炸

所以每次 AI 改完之后，花两分钟跑一下 diff：

怎么看

# AI 改完之后，先看改了什么gitdiff# 如果已经 add 到暂存区了gitdiff--staged

diff 会列出每一个被修改的文件、每一行增删。重点检查：

养成习惯

我现在的流程是固定的：

给 AI 需求 → AI 改代码 → git diff 逐文件过一遍 → 确认无误 → git add + commit

这五分钟的 diff 审查，可能省掉后面五小时的 Debug。

“AI 写代码，你来读 diff。你不读，就没人替你读。”

四、AI 写 Commit Message

如果你已经养成了 git diff 审查的习惯，这一步顺理成章。

传统写 commit message 的问题是：写短了说不清改了什么，写长了懒得写。“fix bug” “update code”“改了一些东西”——这种 commit message 三个月后回头看，完全不知道这次提交干了什么。

但现在你手上就有 AI，而且你已经看过 git diff 了。

怎么做

# 1. AI 改完代码后，先 diff 看改动gitdiff--staged# 2. 把 diff 输出丢给 AI，说一句：# "根据这个 diff，帮我写一条规范的 commit message，中文，50 字以内"

AI 读的是你实际的代码变更，不是猜的——它知道具体改了哪个函数、加了什么逻辑、删了什么冗余。生成的 commit message 一般比你手写靠谱。

但别忘了审查

AI 生成的 commit message 也要看一遍。它不是每次都对，有时候会：

• 把 “重构” 描述成 “修复”
• 漏掉改动中的重要部分
• 描述过于笼统，跟没写差不多

审查只花你十秒钟：读一遍，确认描述和实际改动一致，然后 commit。

一个简单的 AI + Git 工作流

到了这一步，你已经有了一条完整的流程：

AI 改代码
→ git diff 审查改了什么
→ AI 根据 diff 生成 commit message
→ 你确认 → git commit

每个环节人工只做一件事：审查。代码是 AI 写的，commit message 是 AI 生成的，但你始终是最后一道关。

“AI 写代码，AI 写日志，你负责判断。这就是 AI 时代开发者的新角色。”

五、出事了怎么办：Git 救急三件套

AI 批量改代码时，出问题的概率比人工写更大。不是 AI 不行，而是它速度太快——你让 AI连续改十次提交，某次引入了 Bug，排查起来就麻烦了。

这三个命令在 AI 时代使用频率会越来越高：

1、reflog — 时间机器

你让 AI 改代码，改了几次不满意，reset --hard
回到某个版本。然后又后悔了——刚才那个版本其实有个东西是对的。

普通 git log 只显示 commit 历史，已经回退过的 commit 不显示了。这时候用 reflog：

gitreflog

输出类似：

a1b2c3d HEAD@{0}: reset: moving to HEAD~2 e4f5g6h HEAD@{1}: commit: AI 重构用户模块 i7j8k9l HEAD@{2}: commit: AI 修复登录 bug

reflog 记录了你在本地仓库的每一次操作，包括已经"消失"的 commit。找到你想要的，直接跳回去：

gitreset--harde4f5g6h

log 看的是历史，reflog 看的是足迹。AI 改乱了？reflog 把你拉回去。

2、bisect — 定位谁引入的 Bug

AI 连续帮你改了 20 个 commit。某天你发现一个功能坏了，但不知道是哪次提交引入的。

人工排查：一个个 commit 看 diff，找到坏的那个。20 个 commit 可能要翻半天。

bisect 是 Git 内置的二分查找工具：

# 启动二分查找gitbisect start# 标记当前版本是"坏的"gitbisect bad HEAD# 标记某个历史版本是"好的"（那时候功能还正常）gitbisect good a1b2c3d

Git 会自动跳到中间那个 commit，你测试一下功能，告诉它：

gitbisect good# 这个版本没问

Git 继续二分，几轮之后精确定位到引入 Bug 的那次提交。20 个 commit 人工要翻半天，bisect
四五轮就搞定。

bisect 帮你找出"哪次 AI 提交埋了雷"。

3、revert — 安全撤销

发现某个 AI 提交有问题，已经 push 到远程了，怎么办？

reset 不行——reset 改本地历史，push 过的 commit 如果 reset 再 push 会跟远程冲突。

这时候用 revert：

# 生成一个反向 commit，把那次提交的改动"清零"gitrevert<那个有问题的commit ID>

revert 不会删除历史，而是生成一个新的commit，内容是"把那次的改动撤销掉"。安全推送到远程，全队同步，历史干净。

三件套选择指南

AI 写得快，Bug 也来得快。这三个命令就是你的急救包。

五、进阶玩法：Worktree 并行开发

前面聊的都是"防守"——怎么保住代码、怎么回退、怎么审查。这一节聊点进攻性的：用 Git Worktree 让 AI
帮你做并行实验。

什么是 Worktree

正常情况下，一个 Git 仓库只有一个工作目录。你在上面切换分支、改代码。

Worktree 允许你从同一个仓库创建多个工作目录，每个目录对应不同分支，互不干扰。

在主目录的基础上，创建一个独立的工作目录做实验

git worktree add …/project-experiment -b experiment

执行完之后，你有了两个目录：

~/project/ ← 主工作区，正常开发
~/project-experiment/ ← 实验区，AI 在这里撒野

两个目录共享同一份 Git 历史（.git
对象库），但文件物理隔离。主目录改的东西不影响实验区，实验区改乱了不影响主目录。

在 AI 场景下有什么用

想象一个场景：你正在主分支上开发业务功能。突然想试试让 AI 重构某个模块——但你怕 AI 改乱了整个项目。

有了 Worktree：

主 worktree：你正常写代码、提交、push
实验 worktree：丢给 AI，“帮我重构这个模块”，随便改

AI 在实验区改完之后，你可以：

# 切到实验区看看 AI 改了什么cd../project-experimentgitdiffmain# 如果改得好，挑几个 commit 合并到主分支gitcherry-pick<commitID># 如果改得不好，直接删掉cd../projectgitworktree remove../project-experimentgitbranch-Dexperiment

零风险。主项目一行代码都没动过。

更进一步：对比多个 AI 方案

2025-2026 年 AI 编程社区的一个热门玩法：同一个需求，让不同 AI 工具在不同 Worktree 里各自实现，然后择优合并。

# 三个 worktree，三种方案gitworktreeadd../solution-cursor-bfeat/solution-cursorgitworktreeadd../solution-claude-bfeat/solution-claude# 各自让 AI 实现同一个功能# 完工后对比gitdifffeat/solution-cursor feat/solution-claude# 挑好的 merge 或 cherry-pick

你化身评审，AI 是选手。谁的方案好，谁的 commit 就进主分支。

别忘了清理

# 查看所有 worktreegitworktree list# 删掉不需要的gitworktree remove../solution-cursor# 清理已手动删除的 worktree 元数据gitworktree prune

适合什么场景

一个 Worktree 一个任务。AI 的时代，并行实验的成本降到了零。

六、总结

AI 编程工具在快速进化，但有一条主线不会变：代码写得越快，版本管理越重要。

这篇文章的核心观点，浓缩成一张表就够了：

AI 时代 Git 工作流速查

一个公式

AI 负责生成，你负责审查。AI 负责速度，Git 负责安全。

AI 写的代码越来越多、越来越快，你的角色也在变——从"写代码的人"，变成"审查代码的人"。git diff
就是你的审查工具，git commit 是你的安全网，git push 是你最后的决策权。

Git 学了那么多命令，在 AI 时代没有一个是用不上的。反而用得更多了。