你的 AI 做项目的时候，是不是经常这样？
一开始需求是对的。
AI 写着写着，开始自己加东西。
你让它改一个小问题，它顺手动了别的地方。
你再让它修，它又继续往前补。
最后不是完全不能跑。
而是需求已经对不上，代码也越来越乱。
更麻烦的是，前面没有及时存档。
真出问题时，你连一个能退回去的稳定点都没有。
这才是 Git 要解决的问题。
我之前讲过 Git 认知，主要讲为什么用 AI 做项目一定要有 Git 存档。
但是后来我发现，很多人真正开始用的时候，还是会卡住。
比如什么时候初始化仓库，怎么初始化仓库？
什么时候保存版本？
什么时候推到远程？
出了问题，能不能让 AI 回滚？
这几个问题如果没搞清楚，Git 反而会变成新的风险。
一天一个 vibe coding 小技巧。
今天补一篇 Git。
这篇不讲专业命令。
也不要求你变成 Git 高手。
只讲一件事：
没有技术背景的人，怎么让 AI 按正确顺序保存、推送和回滚，别让它替你乱操作。
在开始之前，你需要知道一件事。
本篇不讲怎么安装 Git。
安装 Git 这件事，网上搜一下，下个安装包，一路 next 就行。
实在不确定，就让 AI 检查：
“请检查我电脑上 Git 是否安装成功。如果没有成功，请告诉我下一步该怎么处理。”
真正麻烦的是，装完之后你到底让 AI 怎么用它。
一、先记住：版本不是发布版
在使用 Git 的时候，你往往接触更多的就是版本这个词。
很多人听到“版本”两个字，会下意识以为：
是不是功能完整了？
是不是可以发布了？
是不是用户能用了？
不是。
在 Git 这里，版本更像是项目存档点。
提交一个版本，不等于发布一个功能。
它只是把当前项目状态保存下来。
这就像打游戏。
打到一个关键节点，先存档。
不是说你已经通关了。
而是后面打崩了，还能回到这里。
比如项目骨架搭好了，可以存一次。
数据库连接跑通了，可以存一次。
某个子阶段按实施真源文档做完了，也可以存一次。
它的作用不是证明项目已经完美。
而是防止 AI 后面越改越乱时，你连退路都没有。
二、先让 AI 初始化本地仓库
装好 Git 之后，很多人其实不知道该怎么用。
第一件事，就是先初始化当前项目仓库。
不是说你电脑上装了 Git，这个项目就自动被 Git 管起来了。
而是你还需要初始化仓库。
你不用去理解什么是专业的仓库概念。
你只需要知道，一个项目就是一个仓库。
这一步不用你自己敲命令。
直接告诉 AI：
“请检查当前项目有没有初始化 Git 仓库。如果没有，帮我初始化本地仓库；初始化前先检查内部资料、密钥、本地配置等不要进代码仓库。”
如果 AI 初始化成功后，继续问你要不要推送到远程仓库。
先不要推。
这一步，你只要做好仓库初始化就够了。
三、本地仓库和远程仓库，是两件事
这里先补一个最基础的概念。
本地仓库，就是你电脑里的项目版本记录。
远程仓库，就是 GitHub、Gitee 这类平台上的项目版本记录。
你可以先只在本地用 Git。
也就是说，你的项目只在你自己电脑上保存版本，不一定马上上传到网上。
这对很多刚开始做项目的人来说，反而更安全。
因为你先把本地存档这件事做好。
等你真的需要备份、协作、开源或者部署时，再考虑推到远程仓库。
这里你可以简单理解为：
提交，是本地保存。
推送，是上传远程。
本地提交可以相对勤一点，远程推送必须谨慎一点。
等你以后推送时，本地提交过的版本记录，也会出现在远程仓库里。
四、远程仓库怎么创建和连接
如果你确实准备把项目推到远程仓库，流程也不用复杂化。
第一步，去 GitHub 或者 Gitee 注册账号。
如果你想简单上手，可以选 Gitee；如果你做开源，GitHub 更常用。
第二步，在平台上创建一个新仓库。
如果你不确定该公开还是私有，先选私有。
这个很好理解：私有仓库别人默认看不到，公开仓库别人可能看到里面的内容。
这里需要注意一点，创建仓库时，如果平台问你要不要自动生成 README、许可证这些东西。
你最好什么都不点，直接创建一个空仓库。
这样后面让 AI 连接远程仓库时，麻烦会少一点。
第三步，把平台给你的仓库地址复制出来直接发给 AI，然后这样说：
“这是我刚创建的远程仓库地址：xxx。请帮我把当前本地 Git 仓库关联到这个远程仓库。关联前先检查当前是否已经配置过远程地址、当前仓库状态是否正常。只配置远程地址，不要推送。”
这里的重点是：
配置远程地址，不等于推送。
它只是告诉本地仓库，以后要上传时传到哪里。
配置完后，让 AI 汇报是否成功，不要推送。
等你确认要推了，再进入推送前检查。
另外，不要把账号密码直接发给 AI。
GitHub、Gitee 的登录、授权、令牌这些东西，如果工具需要你在浏览器里登录，就按平台提示操作。
看不懂就让 AI 用大白话解释下一步。
但不要把自己的账号密码当普通文字发给它。
五、什么时候让 AI 提交
什么时候让 AI 做本地提交？
答案不是每改一点就提交。
也不是等整个项目全做完再提交。
最稳的规则是：
每完成一个明确子阶段，并且验收没问题，就提交一次。
比如实施真源文档里有一个子阶段叫“搭建登录页面和登录接口”。
AI 做完之后，不要立刻让它继续下一个阶段。
先让它汇报。
你可以这样问：
“请对照实施真源文档，汇报当前子阶段完成情况。说明本阶段做了什么，改了哪些文件，是否有漏做或多做，做了哪些验证，验证结果是什么。先不要提交。”
注意最后四个字：
先不要提交。
为什么？
因为提交前，你要先知道它到底做了什么。
如果它一边做一边提交，你还没看清楚，就已经把这个状态保存成版本了。
不是不能保存，而是顺序要对：
先汇报，再验收。
你确认当前阶段结果能接受，再让它提交。
这时候你可以说：
“当前子阶段验收通过。请创建一次本地 Git 提交，提交信息用大白话说明这次完成了什么。只提交和本阶段相关的文件，不要提交无关文件。”
这里还有一句很重要：
只提交和本阶段相关的文件。
因为项目里经常会有临时文件、配置文件、个人笔记、内部资料。
不要让 AI 一句“把所有文件都提交了”，把不相关的东西也塞进去。
反过来，AI 试了一堆方案没跑通、自己也说还有问题、改了很多你没让它改的地方，或者验证结果你听不懂，都先不要提交。
先让 AI 解释当前状态、处理多余改动、补齐验证。
只有你听明白它做了什么、怎么证明做完了，再让它提交。
六、什么时候让 AI 推送
推送比提交更敏感。
因为提交只是存在你电脑里。
推送是把东西上传到远程仓库。
一般来说，只有你需要云端备份、换电脑开发、别人协作、开源展示，或者部署平台要求读取远程仓库时，才考虑推送。
不是每次提交完都必须推送。
项目早期、内部资料还没整理、公开私有没确认时，不要急着推。
推送前，先让 AI 检查：
“我现在准备推送到远程仓库了。请先检查当前远程仓库是公开还是私有。本次会推送哪些文件？有没有配置密钥、内部资料、商业计划、真实 case、agent 宪法、实施真源文档、未公开规划等不该上传的内容？先给我检查结果，不要执行推送。”
这段话很重要。
因为很多 AI 项目里，最敏感的未必是代码，而是内部资料、商业计划、真实 case、agent 宪法、实施真源文档这些东西。
代码可以开源，不代表所有内部资料都要一起开源。
所以推送前，先看公开私有、文件清单和敏感内容。
确认完，再决定推不推。
七、怎么处理内部资料
很多项目里都有一类不是代码、但特别重要的文件。
比如立项文档、阶段计划、实施真源文档、agent 宪法、商业策略、真实用户 case 等等。
只要它们跟代码放在同一个项目文件夹里，就要特别小心。
常见做法有两个。
第一种，把它们放进一个内部资料文件夹。
比如叫 dev-docs。
然后明确告诉 AI：
“这个文件夹是内部资料，不允许提交到主代码仓库，也不允许推送到公开远程仓库。”
第二种，如果你又想记录这些内部资料的修改历史，可以单独给这个内部资料文件夹建一个本地 Git 仓库。
也就是说，代码归代码管。
内部资料归内部资料管。
两边不要混在一起。
同时，还要让 AI 确认这个内部资料文件夹已经被主代码仓库排除。
这听起来多一步。
但能避免一个大风险：
你本来只想开源代码，结果把商业计划、产品路线、真实案例、AI 工作规则也一起暴露出去。
如果你不知道当前项目该怎么处理，就不要自己猜。
直接问 AI：
“请检查当前项目里哪些文件属于代码，哪些文件属于内部资料。请给出建议：哪些可以进入主代码仓库，哪些应该排除，哪些如果需要版本管理，应该单独建立本地仓库。先只分析，不要修改。”
重点是：
先分析，不要上来就改。
因为涉及 Git 边界和内部资料，不能让 AI 直接操作。
先看清楚，再决定。
八、什么是 Git 忽略规则
你可能会听到 Git 忽略规则。
它通常写在 .gitignore 这个文件里。
不用理解具体语法，把它当成 Git 的禁止提交清单就行。
哪些文件不应该被 Git 保存，就提前写进这个清单。
比如临时文件、系统缓存、依赖目录、本地配置、密钥文件、内部资料文件夹，一般都不该进代码提交。
但这里要注意一点。
如果某个文件已经被提交过，后面再把它写进忽略规则，它也不会自动从 Git 记录里消失。
所以忽略规则最好在第一次正式提交前就检查好。
对不会代码的人来说，不需要自己手写规则。
你可以直接让 AI 处理。
但你要给它边界：
“请根据当前项目类型，检查 Git 忽略规则是否合理。重点确认临时文件、依赖目录、本地配置、密钥文件、内部资料文件夹是否被排除。先说明检查结果和建议，不要直接修改。”
如果它说需要修改，再让它改，并解释：
“请用大白话说明，这次禁止提交清单里新增了哪些内容，分别是为了防止什么风险。”
这样你不用懂具体规则。
但你知道它在保护什么。
九、回滚不要轻易执行
Git 有用的一点，是可以回到之前的版本。
但回滚这件事，不是发现问题就立刻执行。
什么时候应该考虑回滚？
功能明显漂移、越修越乱、当前状态说不清，或者改动范围突然变大，就先别硬补。
先停下来，考虑要不要回到之前的稳定版本。
但注意，是考虑回滚，不是直接回滚。
如果你还有没保存的改动，AI 已经改了很多文件，或者你根本不知道要回到哪个版本，一句“帮我回滚”就可能把你想保留的东西弄没。
所以正确做法，是先让 AI 把历史版本拉出来对比。
你可以这样说：
“我怀疑当前功能已经漂移。请先不要回滚。请严格审计当前状态：对照实施真源文档，说明当前功能偏离了哪些要求；列出最近几次 Git 提交，每个提交大概做了什么；判断哪个历史提交最接近正确状态，哪个回退方案损失最小；同时说明如果回到那个版本，会丢掉哪些当前改动。先只审计和给方案，不要执行回滚。”
这段话的重点，不是让 AI 立刻回到某个版本，而是先做三件事。
第一，对照实施真源文档，判断现在到底偏到哪里了。
第二，拉出最近几次提交，看哪个版本最接近正确状态。
第三，说明回到那个版本会损失什么，有没有更小的恢复方案。
因为回滚不是找“最近的旧版本”。
而是找“损失最小、最接近正确状态的版本”。
很多时候，也不需要整个项目回滚。
可能只是某个文件被改坏了。
可能只是某个功能写偏了。
那就让 AI 优先给你更小的修复方案。
所以回滚前的顺序是：
先审计，再比较历史版本，再评估损失，最后决定要不要回滚。
十、把 Git 规则写进 agent 宪法
讲到这里你会发现，Git 本身不难。
难的是让 AI 按正确顺序做事。
所以这套规则最好直接写进 agent 宪法：
“Git 版本管理规则：
- 项目开始时，必须先检查当前项目是否已经初始化 Git 仓库。没有初始化时，先检查内部资料、密钥、本地配置等不要进入代码仓库，再初始化本地仓库。
- 每完成一个明确子阶段，必须先对照实施真源文档汇报：本阶段完成了什么，修改了哪些文件，是否有漏做或多做，做了哪些验证，结果是什么。
- 只有在阶段验收通过后，才允许创建本地 Git 提交。
- 配置远程仓库地址前，必须先说明当前是否已经有远程地址、准备配置到哪里。配置远程地址不等于推送，未经确认不得直接推送。
- 未经我明确确认，不允许推送到远程仓库。
- 推送前必须先检查：当前远程仓库是公开还是私有，本次准备推送哪些文件，是否包含内部资料、商业计划、真实 case、配置密钥、agent 宪法、实施真源文档、未公开规划等不该上传的内容。
- 未经我明确确认，不允许执行回滚、重置、删除历史等可能丢失改动的操作。
- 如果怀疑功能漂移或需要回滚，必须先严格审计：对照实施真源文档说明当前偏离了哪些要求；列出最近几次 Git 提交和每次大概做了什么；判断哪个历史提交最接近正确状态，哪个回退方案损失最小；说明当前改动会不会丢失，是否需要先保存当前状态，有没有只恢复某个文件或某个功能的更小方案。
- 不允许把无关文件一起提交。每次提交前必须说明本次准备提交的文件清单。”
这段不用背，直接复制给 AI，让它结合当前项目写进 agent 宪法。
后续开发时，它就有明确规则可以遵守。
十一、最后
这篇补的不是 Git 命令。
而是用 AI 做项目时，最容易被忽略的一件事：
你要给自己留退路。
你越看不懂代码，越不能把所有希望都押在“AI 下一轮能修好”上。
因为 AI 写得快，跑偏、误改、乱推的速度也快。
所以你真正要抓住的，不是一堆专业命令。
而是顺序。
阶段完成后，先汇报，再验收，再提交。
准备推送前，先检查公开私有、文件清单和内部资料。
想回滚时，先审计历史版本，再决定怎么退。
只要这套顺序立住了，Git 就不是一个让你头疼的技术工具。
它会变成你驾驭 AI 的安全防线。
