启鑫的黑板报

标签： Git

  • 使用AI编码时，应该何时初始化Git？我的实践心得

    最近我开始尝试用Vibe Coding的方式来开发项目，让AI来辅助编写代码。在这个过程中，我遇到了一个看似简单但值得深思的问题：应该等项目成型后再使用Git，还是从第一行代码就开始版本控制？

    • 代码决策的审计日志 – 记录了每一步为什么改动
    • AI优化的实验室 – 安全地尝试不同的Prompt和方案
    • 代码质量的守门人 – 通过commit记录强制你思考每一步的意义

    我的建议：项目第一天就运行git init。 这是我在实践中得出的最重要的经验之一。希望对你的AI编码之旅有所帮助！

    1. 为什么传统开发中人们会犹豫？

    在人工编写代码的年代，很多开发者会觉得：项目还不成熟，加入Git可能显得过度设计。等代码稳定了，功能明确了，再导入版本控制。这个想法在某个时代是可以理解的。

    但AI辅助编码改变了游戏规则。

    2. AI编码的独特挑战

    当你使用AI来生成代码时，出现了一些新的情况：

    2.1 生成质量的不确定性

    AI生成的代码可能一次就很完美，也可能需要多次调整。如果没有Git，你很难分辨哪个版本是有效的，哪个引入了bug。

    2.2 Prompt与代码的对应关系

    当某个功能出现问题时，你想回到某个特定的Prompt执行结果来对比。Git commit的message可以记录当时的Prompt，形成代码和指令的完整链条。

    2.3 实验和分支

    AI可能生成多个不同的解决方案。你想同时尝试不同的实现方式，然后选择最优的。分支管理在这里就变得非常有用。

    2.4 快速迭代的代价

    用AI编码的速度很快，一下子就生成了大量代码。如果中间有问题，往往很难定位改动是在哪一步引入的。频繁的小commit可以精确追踪问题源头。

    3. 我的实践结果

    我采用了以下工作流，效果很好：

    3.1 项目初期

    git init
git add .
git commit -m "Initial commit - project setup"

    3.2 每次AI生成重要代码段后

    git add .
git commit -m "Feature: xxx - AI generated with prompt: [prompt关键字]"

    3.3 AI代码需要修改时

    git add .
git commit -m "Fix: xxx - reviewed and adjusted manually"

    这样做的好处显而易见：

    1. 完整的进化链 – 从Prompt到初版代码，再到最终版本，整个过程都记录在案
    2. 快速定位问题 – 如果某个功能出问题，可以通过git log找到相关的所有commit
    3. 安全的实验 – 敢于尝试新想法，因为随时可以回滚
    4. 代码审查友好 – 使用git diff可以清楚看到每个步骤改动了什么
    5. 团队协作准备 – 即使目前是个人项目，这个习惯为未来团队合作打好基础

    4. 关键点

    4.1 Commit Message要清晰

    一定要在message中标注资源来源：

    • "Feature: xxx - AI generated" – 表示AI生成
    • "Fix: xxx - manual review"– 表示手工调整

    这样回头查看时一目了然。

    4.2 创建.gitignore

    从项目初期就排除不必要的文件：

    node_modules/
__pycache__/
.env
*.log
build/
dist/
.DS_Store

    针对你的项目类型调整即可。

    4.3 考虑创建分支

    对于不确定性较大的功能，创建特性分支尝试：

    git checkout -b feature/experimental-ai-solution
# AI生成代码并测试
git add .
git commit -m "Experiment: xxx"
# 如果成功，合并到main
git checkout main
git merge feature/experimental-ai-solution

    4.4 定期推送到远程

    即使没有团队合作，也建议推送到GitHub或其他平台作为备份：

    git remote add origin https://github.com/你的账号/项目名.git
git push -u origin main

  • 如何从 Git 历史中彻底删除误上传的敏感信息

    如果你不小心提交了包含敏感信息（如 API 密钥、数据库密码）的 .env 文件到 Git 仓库，需要 彻底删除 这个文件及其历史记录，以防泄露。以下是完整的处理步骤。

    1. 立即更改敏感信息

    重要！ .env 文件中的密码和密钥可能已经泄露，立即更改相关凭据，如：

    • 数据库密码
    • API 密钥
    • OAuth 令牌
    • SSH 私钥

    2. 确保 .env 文件不会再被提交

    将 .env 添加到 .gitignore，防止再次提交：

    echo ".env" >> .gitignore
git add .gitignore
git commit -m "Add .env to .gitignore"

    3. 从 Git 历史中删除 .env 文件

    推荐方式：使用 git filter-repo

    git filter-repo 是 Git 官方推荐的工具，速度快且更安全。

    3.1 安装 git filter-repo

    如果尚未安装，可以运行：

    pip install git-filter-repo

    3.2 彻底删除 .env 文件

    在 Git 仓库根目录运行：

    git filter-repo --path .env --invert-paths

    参数解析：

    • --path .env：指定要删除的文件
    • --invert-paths：删除所有提交中 .env 文件的历史记录

    4. 验证 .env 是否彻底删除

    检查 .env 是否仍在历史记录中：

    git log -- .env
git log -S"你的敏感信息"

    如果没有返回任何记录，说明 .env 文件及其历史已经删除。

    5. 强制推送到远程仓库

    由于改写了 Git 历史，必须使用 --force 强制推送：

    git push origin main --force

    注意：

    • 所有协作者 需要重新克隆仓库，否则 git pull 会失败。
    • 确保 .env 不会再提交（参考步骤 2）。

    6. 清理本地和远程的旧引用

    如果 .env 可能出现在其他分支，确保所有分支都清理干净：

    git push origin --all --force

    7. 确保 .env 在远程仓库中消失

    前往 GitHub / GitLab 仓库，检查 .env 是否仍然可见：

    • 如果仍然存在，可能是缓存未清除，联系托管平台的技术支持要求彻底清除。

    8. 预防未来类似问题

    • 使用 .gitignore 确保敏感文件不会进入 Git 版本控制
    • 使用环境变量管理工具（如 dotenv）存储敏感数据
    • 定期检查 Git 提交，避免误提交敏感信息：
    git log -p | grep "API_KEY"

    重要提醒

    • 备份代码：执行 git filter-repo 之前，建议 备份仓库，以防误删。
    • 通知协作者：如果有其他人参与该仓库开发，他们需要重新克隆仓库，否则会遇到同步问题。
    • 合规性问题：如果泄露的是 用户数据，请考虑是否需要上报安全事件
    • 对于 GitHub 仓库：如果 .env 仍然可见，可以尝试 GitHub API 请求删除缓存或联系 GitHub 支持。
    • 对于 GitLab：使用 git gc --prune=now 清理本地仓库，并在 GitLab 管理面板中触发仓库垃圾回收。
    • 企业环境：如果 Git 服务器由企业管理可与管理员协商执行全局清理。