Git 妙用

Git 用来记录文件变化：改了什么、什么时候改的、能不能回到以前、能不能和别人同步。它不只适合程序员，也适合文档、日记、知识库和 AI 写作。

让 AI 改代码或文档时，Git 可以把边界留清楚：AI 改了哪些文件、具体改了哪里、能不能审查、能不能撤回。

常见用法：

场景	Git 能帮什么
代码编辑	保存每次功能修改，审查 AI 改动，必要时回到旧版本
日记	每天保存一次，回看某天写了什么，误删后可以找回
知识库	记录笔记变化，知道某个结论是什么时候加进去的
文档	保存每次修订，适合教程、合同草稿、项目说明
备份	本地一份，远端一份，电脑坏了也能恢复
团队项目	多个人共享同一批文件，知道谁改了哪里
AI 写作或 AI 编程	让 AI 修改前后都有记录，方便审查和撤回

使用时不用先背命令。把目标说清楚，让 AI 帮你检查当前状态、执行 Git 操作、解释结果。下面的提示词可以直接复制给 Codex、ChatGPT、豆包、DeepSeek 或其它能操作本地文件的 AI 工具。

先说清楚边界

不熟悉 Git 时，在提示词里明确禁止 AI 直接执行 reset --hard、git clean -fd、强制推送等破坏性操作。需要删除、覆盖、回退大量文件时，必须让 AI 先解释影响，再等你确认。

初始化一个 Git 仓库

适合第一次把一个文件夹交给 Git 管理。

把下面复制给 AI：

请帮我把当前项目初始化为 Git 仓库。
要求：
1. 先确认当前目录路径和文件列表，避免在错误目录操作。
2. 如果已经是 Git 仓库，就不要重复初始化，只说明现状。
3. 如果不是 Git 仓库，再执行初始化。
4. 初始化后创建或检查 .gitignore，避免把密钥、缓存、依赖目录、构建产物提交进去。
5. 最后告诉我下一步应该如何做第一次提交。
不要执行远端推送。

初始化就是让 Git 开始记录这个文件夹的变化。.gitignore 是“不要记录这些文件”的清单，常见的有密钥文件、日志、缓存、node_modules、构建输出目录。第一次初始化时先处理忽略规则，比后面误提交敏感文件再清理更稳。

让 AI 修改代码前先建立安全边界

适合让 Codex 或其它编程 AI 修 bug、改页面、补接口、改脚本之前使用。

把下面复制给 AI：

请先帮我检查当前 Git 状态，然后再开始修改代码。
要求：
1. 先运行 git status，确认当前有没有未提交修改。
2. 如果已有未提交修改，请先告诉我这些修改是什么，不要覆盖或回退。
3. 修改前说明你准备改哪些文件，为什么要改。
4. 修改后运行 git diff，总结具体改动。
5. 如果项目有测试或构建命令，请运行最相关的验证命令。
6. 不要自动提交，等我确认 diff 和验证结果后再提交。

这段提示词的重点不是命令本身，而是让 AI 先尊重当前工作区。很多代码项目里，未提交修改可能是你自己刚写的内容，也可能是另一个人改到一半的内容。先看 git status 和 git diff，可以避免 AI 把已有工作混在一起，最后不知道问题是谁引入的。

让 AI 修 bug 后提交代码

适合 AI 已经完成一个小修复，并且你想把它保存成一次清楚的代码提交。

把下面复制给 AI：

请帮我审查并提交这次代码修改。
要求：
1. 先运行 git diff，总结本次代码修改解决了什么问题。
2. 检查有没有无关格式化、调试日志、临时文件、密钥或大文件。
3. 如果有测试，请说明已经运行了哪些测试，以及结果是什么。
4. 只提交和这次 bug 修复相关的文件。
5. 提交信息用简洁中文，例如“修复登录表单校验问题”。
6. 提交后运行 git status，确认没有漏提交的相关文件。

代码提交最好围绕一个清楚目标：修一个 bug、加一个功能、改一段文档、补一组测试。不要把多个无关修改混在一次提交里。以后排查问题时，提交越清楚，越容易定位是哪次修改引入了问题。

做第一次提交

适合初始化之后，把当前版本保存成一个清楚的起点。

把下面复制给 AI：

请帮我做第一次 Git 提交。
要求：
1. 先运行 git status 和 git diff，说明将要提交哪些文件。
2. 检查是否有 API Key、密码、token、私密聊天记录、大体积缓存或构建产物。
3. 如果发现敏感或不该提交的文件，先停下来告诉我，不要提交。
4. 如果没有问题，把合适的文件加入暂存区。
5. 使用简洁的中文提交信息，例如“初始化文档仓库”。
6. 提交完成后告诉我提交编号和当前状态。

一次提交可以理解成一个“存档点”。以后你想知道这一版有哪些文件、写了什么内容，或者想回到这一版，都可以通过提交记录找到。好的提交信息不需要很长，但要让人看得懂这次保存的目的。

保存今天的修改

适合日常写文档、写日记、改知识库、改代码后，把当天成果保存下来。

把下面复制给 AI：

请帮我保存当前修改到 Git。
要求：
1. 先查看 git status 和 git diff，总结本次改动内容。
2. 如果改动很多，请按主题建议拆成几个提交，但先问我是否同意。
3. 检查是否有敏感信息或不该提交的临时文件。
4. 没有问题后再提交。
5. 提交信息用中文，格式尽量简洁，例如“更新 Git 妙用文章”。
6. 提交后再次查看 git status，确认工作区是否干净。

日常使用 Git，最常做的是三件事：看状态、看差异、提交。status 告诉你哪些文件变了，diff 告诉你具体改了什么，commit 把这次修改保存成历史记录。让 AI 先总结差异，可以帮你避免把没检查过的内容直接提交。

推送到远端仓库

适合把本地仓库同步到 GitHub、Gitee、GitLab 或公司内部 Git 服务。

把下面复制给 AI：

请帮我把当前 Git 仓库推送到远端。
远端仓库地址是：<把你的仓库地址粘贴在这里>
要求：
1. 先检查当前是否有未提交修改；如果有，先停下来问我是否要提交。
2. 检查是否已经配置 remote。
3. 如果没有 remote，请把上面的地址配置为 origin。
4. 推送前说明将要推送的本地分支和远端分支。
5. 不要执行强制推送。
6. 推送完成后告诉我远端地址和当前分支状态。

远端仓库就是放在服务器上的副本。它既可以当备份，也可以用来多人协作。本地提交只保存在自己电脑上；推送之后，远端才会有这次记录。第一次推送前一定要确认仓库地址，避免把内容推到错误项目。

每天自动保存日记或知识库

适合 Obsidian、Markdown 笔记、日记、资料库这类经常修改但不一定写代码的目录。

把下面复制给 AI：

请帮我为这个日记或知识库目录设计一个简单的 Git 保存流程。
目标：
1. 每次保存前先检查有哪些文件变化。
2. 默认只提交 Markdown、图片和附件，不提交缓存、插件临时文件、密钥或系统文件。
3. 提交信息包含日期和简单说明。
4. 如果适合自动化，只给我一个最简单的脚本方案，并解释怎么手动运行。
5. 不要配置复杂 CI，不要做无人值守推送，先以手动确认为主。

Git 用在日记和知识库时，不需要复杂流程。最重要的是把“每天的变化”保存下来，并排除缓存和隐私文件。自动化可以有，但一开始不要急着做无人值守推送，因为笔记里经常会混入私人内容，手动确认更安全。

找回以前的内容

适合误删、改坏、想看旧版本，但还不确定要不要回退。

把下面复制给 AI：

请帮我查找 Git 历史，找回某个文件以前的内容。
文件路径是：<填写文件路径>
我想找的内容大概是：<描述关键词或时间>
要求：
1. 先只查看历史和差异，不要直接覆盖当前文件。
2. 找到可能的版本后，告诉我提交时间、提交信息和相关改动。
3. 如果需要恢复，请先给出恢复方案，等我确认后再操作。
4. 不要执行 reset --hard。

Git 的历史记录不是只能“整体回退”。你可以只查看某个文件的旧内容，也可以只恢复某个文件。新手不要一上来就让 AI 回滚整个仓库，先让它查历史、解释差异，再决定恢复哪一部分。

开一个分支试验新想法

适合让 AI 大改一版文章、重构一批文件、尝试某个新方案，但又不想影响当前稳定版本。

把下面复制给 AI：

请帮我为这个任务创建一个 Git 分支。
任务目标是：<描述你要试验的事情>
要求：
1. 先确认当前工作区是否干净；如果不干净，先说明有哪些未提交内容。
2. 创建一个语义清楚的分支名。
3. 切换到新分支后再开始修改。
4. 修改完成后总结这个分支相对主分支改了什么。
5. 不要自动合并回主分支，等我确认。

分支可以理解成“另开一条路线”。主分支保持稳定，新分支用来试错。尤其是让 AI 做大范围修改时，先开分支会更安全：不满意就放弃分支，满意再合并。

提交前让 AI 做一次审查

适合你已经改完，但想在提交前知道有没有明显问题。

把下面复制给 AI：

请作为审查者检查我当前未提交的 Git 改动。
要求：
1. 先读取 git diff，不要修改文件。
2. 优先指出明显错误、遗漏文件、敏感信息、无关改动和可能影响运行的问题。
3. 如果只是文字或文档修改，也要检查链接、标题层级、示例是否前后一致。
4. 最后给出是否建议提交，以及建议的提交信息。

这一步不是让 AI 继续发挥，而是让它先当审查员。很多问题在提交前看一眼差异就能发现，比如误删段落、链接写错、把临时文件带进去、提交信息和实际修改不一致。

团队协作前先同步

适合多人一起改同一个远端仓库。

把下面复制给 AI：

请帮我在开始修改前同步远端仓库。
要求：
1. 先检查当前是否有未提交修改。
2. 如果有未提交修改，不要直接拉取，先告诉我风险。
3. 如果工作区干净，再拉取远端最新内容。
4. 如果出现冲突，请解释冲突文件和冲突原因，不要擅自删除任何一方内容。
5. 同步完成后告诉我当前分支是否已经是最新。

团队协作时，本地文件可能落后于远端。开始修改前先同步，可以减少冲突。冲突并不可怕，它只是说明两边改到了同一块内容；关键是不要让 AI 直接丢弃某一方修改，应该先解释再处理。

常用概念用人话理解

概念	可以这样理解
仓库	被 Git 管理的文件夹
工作区	你电脑上正在编辑的文件
暂存区	准备放进下一次提交的文件清单
提交	一个可回看的存档点
提交信息	这次存档的说明
差异	当前文件和上次保存相比改了什么
分支	从同一份内容分出来的一条试验路线
合并	把一条分支的成果并回另一条分支
远端	放在 GitHub、Gitee、GitLab 等平台上的仓库副本
推送	把本地提交同步到远端
拉取	把远端更新同步到本地
忽略文件	明确告诉 Git 不要记录的文件

深入一点：几个基础 Git 命令

不需要一开始背很多命令。先看懂下面这些，就能理解 AI 在帮你做什么。

看当前状态

git status

这个命令用来查看当前仓库有没有改动、哪些文件还没提交、当前在哪个分支。让 AI 操作 Git 前，通常第一步就是它。

看具体改了什么

git diff

这个命令会显示当前文件相对上次提交改了哪些内容。代码编辑时很重要：AI 改完代码后，你可以让它解释 git diff，确认没有多改、误删或混入敏感信息。

把文件加入下一次提交

git add 文件路径

例如：

git add docs/external/git-practical.md

git add 不是最终保存，它只是把文件放进“准备提交”的清单。代码项目里按文件或按主题添加，不要不检查就直接提交所有文件。

提交一次修改

git commit -m "更新 Git 妙用文章"

提交就是保存一个版本点。-m 后面是提交信息，应该写这次改动的目的。代码项目可以写“修复支付回调验签问题”“新增用户导出接口”“补充登录失败测试”。

查看提交历史

git log --oneline

这个命令会用简短形式显示历史提交。你想找某次改动、回看以前的版本，通常会先从这里开始。

推送到远端

git push

推送是把本地提交同步到远端仓库。第一次推送可能需要指定远端和分支，普通用户可以让 AI 帮你判断，不要自己硬猜。

从远端拉取最新内容

git pull

多人协作时，开始修改前经常要先拉取远端最新内容。拉取前最好先确认本地没有未提交修改，否则可能出现冲突。

查看远端地址

git remote -v

这个命令能看到当前仓库连接的是哪个远端。第一次推送、换电脑、排查推送失败时很有用。

一个最小命令流程

只保存一次修改时，最小流程是：

git status
git diff
git add 文件路径
git commit -m "说明这次修改"
git push

真正使用时，让 AI 先解释每一步会做什么，再执行。你不需要把所有命令都背下来，但要知道 AI 运行这些命令是在检查状态、查看差异、选择文件、保存版本、同步远端。

新手不要直接让 AI 做的事

操作	风险
reset --hard	会把当前未保存修改直接丢掉
git clean -fd	会删除未被 Git 跟踪的文件
强制推送	可能覆盖远端历史，影响别人
大范围自动合并	容易把冲突处理错
自动提交所有文件	可能混入密钥、缓存、临时文件
无人值守推送私人笔记	可能把隐私内容同步到远端

确实需要这些操作时，提示词里加一句：先解释影响，不要执行，等我确认后再做。

一个最稳的日常流程

普通用户不需要一开始学完整 Git。先记住这个流程就够用：

1. 修改文件前，让 AI 检查当前 Git 状态。
2. 修改完成后，让 AI 总结 git diff。
3. 确认没有敏感信息和无关文件。
4. 让 AI 提交，并写清楚提交信息。
5. 需要备份或协作时，再推送到远端。

Git 的价值不在于背多少命令，而在于每次修改都有边界、有记录、能审查、能找回。把这些边界告诉 AI，AI 就能更稳地帮你初始化仓库、保存修改、推送远端、找回旧内容和处理协作问题。