如何在 AI 构建的应用中使用 Git

要在 AI 构建的应用中使用 Git，请把项目连接到一个 Git 仓库，每次有效的修改之后提交，用一行话写清楚改了什么，并通过 .gitignore 把机密信息排除在外。风险较高的工作使用分支；如果别人改过代码，再次写提示词之前先拉取；当 AI 弄坏了东西时，回到上一个正常的提交，而不是在混乱的基础上继续写提示词。

Git 是版本控制工具，记录你的代码每一个保存过的版本。GitHub 是在线存放 Git 仓库的网站。如果这些概念对你来说还很陌生，可以先看 什么是 GitHub。本指南讲的是：当 AI 写了大部分代码时，哪些习惯能让 Git 真正发挥作用。

为什么 AI 开发时 Git 更重要

AI 一轮就可能修改二十个文件。速度很快，但也意味着一条提示词可能悄悄弄坏你昨天刚测试过的功能。Git 为你提供：

• 一条退路。 任何已提交的版本都可以恢复。
• 修改记录。 你可以清楚看到某条提示词改动了哪些文件、哪些行。
• 构建工具之外的副本。 你的代码保存在你自己掌控的地方。
• 标准的交接方式。 任何开发者、托管平台或工具都可以基于一个 Git 仓库工作。

第一步：连接仓库

在 GitHub 或类似服务上创建一个仓库（通常设为私有），然后把项目连接到它。大多数支持 Git 的 AI 应用构建工具都通过设置页面里的“连接 GitHub”按钮完成这一步。如果你的工具没有这个功能，可以导出代码后自己推送，或者请开发者帮你设置一次。

第一次推送之前，确保仓库忽略了不该进入的内容：

检查 .gitignore 文件。确保它排除了 .env 文件、node_modules、构建输出目录以及任何包含机密信息的文件。告诉我你添加了哪些内容。

第二步：每次有效修改后提交

提交就是带有说明信息的一次保存快照。最重要的习惯是：当某项功能正常工作时就提交，然后再提出下一个需求。

1. 针对一项修改写提示词。
2. 在预览中检查效果。
3. 如果没问题，带着说明信息提交（或同步）。
4. 然后再继续。

提交小，意味着出问题时你知道是哪一次修改导致的，撤销它时也不会丢掉其他工作。

第三步：写能看懂的提交信息

好的提交信息用一行话说明改了什么、为什么改：

• 好：在订单页面添加 CSV 导出
• 好：修复预订表单在晚上 6 点后拒绝时间的问题
• 没用：更新、改动、修一下

你也可以让 AI 来写：

用一行话总结自上次提交以来的改动，以动词开头，不超过 70 个字符。

第四步：风险较高的工作使用分支

分支是一条独立的工作线。你可以在分支上尝试某个改动，如果行不通，直接放弃，而不影响主版本。

以下情况适合使用分支：

• 改动较大（重新设计、新的支付流程、数据库变更）。
• 有其他人也在改同一个应用。
• 你希望在上线前让别人审查这次改动。

工作完成并测试通过后，它会被 合并 回主分支。在 GitHub 上，这通常通过 拉取请求（pull request） 完成，即一个展示改动以供审查的页面。如果你的构建工具只同步一个分支，开发者可以在 GitHub 端管理分支。

第五步：安全地撤销

当一条提示词弄坏了应用，不要急着在混乱之上再连续写五条提示词。请回到上一个正常的版本，然后用更清楚的提示词重新尝试。

• 在构建工具中： 如果有检查点或恢复功能，就使用它。
• 在 Git 中： git revert 会创建一个新的提交来撤销旧的提交，历史记录保持完整。对于别人可能已经拉取过的代码，这是安全的选择。
• 避免在共享分支上使用 git push --force，除非你非常清楚原因。它会为所有人重写历史。

如果你不确定，可以这样问：

上一次改动弄坏了登录页面。请对比上一次提交，告诉我它改动了哪些文件，并解释每处改动的作用。先不要修改任何内容。

第六步：提示之前先拉取

如果开发者或其他工具在 GitHub 上修改了代码，AI 构建工具在你把这些更改拉取进来之前是不知道的。在旧代码上写提示词，会导致冲突和工作丢失。

• 每次开始工作时都先拉取。
• 约定好谁负责修改哪些部分，避免双方同时修改同一个文件。
• 如果出现 合并冲突（同一行被两边都改了），请让开发者或 AI 来解决，并解释选择的理由。

示例提示词

开始之前：自我上次会话以来，仓库里有哪些变化？请总结这些提交。

单独完成下一项修改：为每张发票添加一个“复制”按钮。不要改动其他任何内容，这样我可以单独提交它。

检查 Git 中是否有任何 API 密钥、密码或 .env 文件被跟踪，包括过去的提交。只报告文件名，不要报告具体内容。

常见错误

• 提交了机密信息。 一旦密钥进入 Git 历史，即使删除了文件，它也已经暴露。请更换该密钥。
• 每周只做一次巨大的提交。 你无法只撤销其中一个改动，而不撤销全部。
• 提交信息写“更新”。 历史记录就无法用来找出是哪里出了问题。
• 基于过时的代码写提示词。 如果别人也在编辑，先拉取。
• 用强制推送修复错误。 它可能抹掉别人的工作。应该用 revert。
• 提交了 node_modules。 它很大，而且反正可以通过锁文件重新生成。

检查清单

• 项目已连接到一个私有仓库。
• .gitignore 排除了 .env、node_modules、构建输出和机密信息。
• 每次有效修改之后都会提交。
• 提交信息用一行话说明改了什么。
• 较大或有风险的改动放在分支上，并经过审查。
• 如果别人也在编辑代码，写提示词之前先拉取。
• 我用检查点或 git revert 撤销，而不是强制推送。
• 任何曾经被提交过的密钥都已更换。

Mythex 中的 Git

Mythex 会在每一轮成功的智能体操作之后保存一个 Git 检查点，回退到此处 会把项目恢复到该检查点，也就是第五步所说的构建工具端撤销。参见 通过迭代修改而无需重建。

在 Pro 版本中，GitHub 同步 可以在项目设置中连接一个仓库，让你对其进行推送和拉取；导出 会下载项目，且不包含机密信息和 node_modules。参见 GitHub、导出与导入。在把项目交给开发者之前先连接 GitHub，交接会简单得多，参见 如何与开发者合作开发 AI 构建的应用 和 如何导出并自托管 AI 构建的应用。

常见问题