以生信/数据分析为例，重点讲解 AI 写代码时如何用 Git 保护你的工作。
一句话：Git 是一个"实验记录本"，帮你记录分析代码的每一次变化，随时可以回到过去。
做过生信分析的人一定经历过这种噩梦：
RNA-seq_pipeline_v1.py
RNA-seq_pipeline_v2_改了参数.py
RNA-seq_pipeline_v3_老师说改回去.py
RNA-seq_pipeline_v3_最终版.py
RNA-seq_pipeline_v3_最终版_真的最终.py ← 你在这里
有了 Git → 你只需要 一个文件 pipeline.py，Git 帮你记住所有修改历史。想回到任何版本，一条命令就够了。
Git 管理文件时有 四个关键区域，理解它们就理解了 Git 的 80%：
生信人的类比
- 工作区 = 你的分析目录（正在调试的 R/Python 脚本）
- 暂存区 = 实验记录本的草稿页（选好要记录的改动）
- 本地仓库 = 你的实验记录本（正式存档，可追溯）
- 远程仓库 = 课题组的共享服务器（备份 + 协作）
以一个 RNA-seq 分析为例：
关键点
commit -m后面的描述非常重要！三个月后你回头看，这段话就是你唯一的线索。好的描述 = 好的实验记录。
分支就像平行宇宙：你可以在不影响已有结果的情况下，去试验新方法。
生信中常见的分支用法
main→ 主分支，保存确认可用的分析流程try/deseq2vstry/edgeR→ 对比不同工具fix/normalization→ 修复某个步骤的问题explore/new-clustering→ 试验新的聚类方法
| 场景 | 举例 |
|---|---|
| 分析脚本 | R/Python/Shell 流程脚本、Snakemake/Nextflow pipeline |
| 参数调优 | 改了阈值、换了算法 → Git 记录每次变化和原因 |
| 论文复现 | 审稿人要求复现结果 → Git 精确回到当时的代码版本 |
| 团队协作 | 多人共同开发分析流程，各做各的分支再合并 |
| AI 写代码 | ==让 AI 帮你写/改代码时，Git 是你的"安全网"==（下面重点讲） |
| 内容 | 原因 | 替代方案 |
|---|---|---|
| 原始测序数据（FASTQ/BAM） | 文件太大，几十 GB | 放数据库（SRA/GEO）或 NAS |
| 大型结果文件（矩阵、图片） | 频繁变化 + 占空间 | .gitignore 忽略，单独备份 |
| 数据库密码、API 密钥 | 安全风险 | 环境变量或 .env 文件 |
推荐的项目结构my_rnaseq_project/ ├── scripts/ ← ✅ Git 管理 │ ├── 01_qc.sh │ ├── 02_align.sh │ ├── 03_deseq2.R │ └── utils.py ├── config/ ← ✅ Git 管理（参数文件） ├── results/ ← ❌ .gitignore 忽略 ├── data/ ← ❌ .gitignore 忽略 ├── README.md ← ✅ Git 管理 └── .gitignore
这是本文最重要的部分。当你让 Claude Code、Codex 等 AI 帮你写分析代码时，AI 可能会：
Git 就是你对抗这些风险的最佳武器。
你有一个已经能跑通的 DEG_analysis.R，现在想让 AI 帮你加一个火山图（Volcano plot）。
用自然语言操作（生信场景）
你对 AI 说的话 背后的 Git 操作 为什么重要 "先帮我保存当前进度" git commit -m "..."==建立安全基线== "新开一个分支来加火山图" git checkout -b feat/volcano==隔离 AI 的改动== "让我看看你改了什么" git diff==逐行审查== "这个改动不对，撤回去" git checkout .==一键回退== "改得不错，保存吧" git add . && git commit确认后才正式保存 "合并到主分支" git merge feat/volcano确认安全后合并
AI 写代码时必须遵守的 Git 规则1. 🔒 先 commit 再让 AI 动手 让 AI 改代码之前，务必先保存当前能用的版本。这是你的"存档点"。
2. 🌿 永远在新分支上让 AI 工作 绝不让 AI 直接修改 main 分支。万一改坏了，整个分支丢弃就行。
3. 🔍 每次都 review AI 的 diff AI 改完后，用
git diff或让 AI 告诉你它改了什么。==不看 diff 就 commit 是最危险的操作。==4. 🧩 小步提交，不要攒一大堆 让 AI 每完成一个小功能就 commit 一次。这样出问题时能精确回退到某一步，而不是全部推倒重来。
5. 📝 commit 描述要写清楚 "
AI 生成的火山图代码，参数: padj<0.05, log2FC>1" 比 "更新代码" 有用一万倍。6. 🚫 告诉 AI 别动不该动的文件 明确指示："只修改
03_deseq2.R，不要动其他文件"。
.gitignore 保护敏感文件有些文件你绝对不希望 AI 提交到 Git 里：
# .gitignore 示例（生信项目）
# 原始数据
data/*.fastq.gz
data/*.bam
data/*.sam
# 大型结果文件
results/*.rds
results/*.h5ad
results/figures/
# 环境和密钥
.env
*_credentials.json
.Rhistory
.RData
# 临时文件
*.tmp
__pycache__/
.snakemake/
| 😱 发生了什么 | 🛠️ 怎么救 | 命令 |
|---|---|---|
| AI 改坏了文件，还没 commit | 撤销工作区的修改 | git checkout . |
| AI 改坏了，已经 commit 了 | 撤销最近一次 commit（保留文件） | git reset --soft HEAD~1 |
| AI 改坏了，commit 了好几次 | 回到某个安全版本 | git log 找到版本号 → git revert <版本号> |
| AI 删了某个文件 | 从历史中恢复 | git checkout HEAD -- 文件名 |
| 整个分支都废了 | 直接丢弃，回到 main | git checkout main && git branch -D 坏分支 |
| 想看 AI 总共改了什么 | 对比分支差异 | git diff main..AI分支名 |
理解了如何保护自己之后，我们来看看怎么高效地利用 AI 管理 Git。
同时让多个 AI 做不同的分析任务，互不干扰：
可复现性 = Git 仓库 + 版本号越来越多的期刊要求附上代码仓库链接。Git 让你的分析可复现：审稿人可以 checkout 到你论文中引用的那个版本，精确重跑你的流程。
| 工具/插件 | 功能 | 获取方式 |
|---|---|---|
| 内置 Git 操作 | 提交、分支、推送、PR 全流程 | Claude Code 自带 |
| Git Worktrees 技能 | 创建隔离的工作副本，支持并行分析 | npx skills add 安装 |
| Changelog Generator | 从 Git 历史自动生成更新日志 | 社区 Skill |
| Code Review 插件 | 多 Agent 并行审查代码 | 官方插件 |
| 工具/插件 | 功能 | 获取方式 |
|---|---|---|
/review 命令 | 内置代码审查，分析 diff 给出风险报告 | Codex CLI 自带 |
| GitHub Action | CI/CD 集成，自动审查 | openai/codex-action |
| GitHub @codex | 在 PR/Issue 中 @codex 触发任务 | GitHub App |
核心观点Git 命令不用死记硬背，AI 可以帮你执行。 但你必须理解三件事：
- ==commit 前先想清楚==（建立安全基线）
- ==AI 改完必须 review diff==（这是你的最后防线）
- ==不确定就开新分支==（随时可以丢弃，不影响已有成果）