版本控制：Git基础、GitHub使用

一句话概述

Git是程序员的时间机器——每次改动都留下快照，随时可以穿越回任意历史版本；GitHub是代码的社交平台，让全球开发者协作共建。两者联手，让你的AI项目再也不怕改坏代码、丢数据、协作冲突。

💡 核心要点：①Git是分布式版本控制系统，记录文件的每一次变更历史 ②仓库/提交/分支是Git的三大核心概念 ③GitHub提供远程仓库托管和团队协作（fork/clone/PR）④AI项目中版本控制是数据版本、模型版本、实验追踪的基石

教学与演示

一、Git基础概念：仓库、提交、分支

是什么：Git是一个分布式版本控制系统，由Linux之父Linus Torvalds于2005年创建。它通过「仓库（Repository）」管理项目文件，通过「提交（Commit）」记录每次变更，通过「分支（Branch）」支持并行开发。

大白话：Git就像一个超级存档系统——打游戏时你可以在关键节点存档，打Boss失败就读档重来。仓库就是整个游戏，提交就是每次存档，分支就是你在同一关卡尝试不同打法，互不影响。

为什么：没有版本控制，代码管理就是一场灾难——project_v1.py、project_v2_final.py、project_v2_final_real.py满天飞。Git让你每次改动都有据可查，随时回退，多人协作不冲突。在AI领域，模型训练动辄几十小时，版本控制确保每次实验都可追溯、可复现。 怎么做：

import numpy as np

# ============================================
# Git 核心概念演示：仓库、提交、分支
# 用 numpy 模拟版本快照和分支结构
# ============================================

print("=" * 50)
print("📦 Git 核心概念：仓库、提交、分支")
print("=" * 50)

# --- 1. 仓库（Repository）---
# 仓库 = 项目文件夹 + Git版本历史
# 实际终端命令：
# $ git init                    # 初始化仓库
# $ git clone <url>             # 克隆远程仓库
print("\n【概念1】仓库（Repository）")
print("  仓库 = 项目文件夹 + .git隐藏目录（版本历史）")
print("  就像一个带监控录像的房间——所有改动都被记录")

# --- 2. 提交（Commit）---
# 每次提交 = 一个版本快照
# 用numpy模拟：每次提交记录文件的哈希值
print("\n【概念2】提交（Commit）— 版本快照")

# 模拟三次提交的文件内容快照
snapshot_v1 = np.array([1, 0, 0, 0])   # 版本1：初始代码
snapshot_v2 = np.array([1, 1, 0, 0])   # 版本2：添加了数据处理
snapshot_v3 = np.array([1, 1, 1, 0])   # 版本3：添加了模型训练

# 计算每次提交的"哈希值"（用numpy简单模拟）
def simple_hash(arr):
    """用numpy计算数组的简单哈希值，模拟Git的SHA-1"""
    # 将数组元素加权求和再取模，模拟哈希
    weights = np.array([7, 13, 17, 23])  # 权重系数
    hash_val = np.sum(arr * weights) % 9973  # 取模得到"哈希"
    return f"a1b2c{hash_val:04d}"  # 格式化为类似Git哈希的字符串

commits = [
    ("c1001", "初始化项目", snapshot_v1),
    ("c1002", "添加数据预处理模块", snapshot_v2),
    ("c1003", "添加模型训练脚本", snapshot_v3),
]

for cid, msg, snap in commits:
    h = simple_hash(snap)  # 计算快照哈希
    print(f"  提交 {cid} | 哈希: {h} | 信息: {msg}")
    print(f"    快照内容: {snap}")

# --- 3. 分支（Branch）---
# 分支 = 从某个提交分叉出的独立开发线
print("\n【概念3】分支（Branch）— 并行开发线")

# 用numpy展示分支结构：主线和实验分支
main_branch = np.array([1, 1, 1, 0])    # 主分支：稳定代码
exp_branch = np.array([1, 1, 0, 1])     # 实验分支：尝试新算法

# 计算两个分支的差异
diff = main_branch - exp_branch  # 差异向量
print(f"  主分支(main):  {main_branch}")
print(f"  实验分支(exp): {exp_branch}")
print(f"  差异向量:      {diff}  (非零位置=不同之处)")
print(f"  差异文件数:    {np.count_nonzero(diff)}")

# 实际终端命令：
# $ git branch experiment    # 创建分支
# $ git checkout experiment  # 切换分支
# $ git switch experiment    # 切换分支（新语法，推荐）

$$ \text{Commit Hash} = \text{SHA-1}(\text{tree} \parallel \text{parent} \parallel \text{message}) $$

大白话：Git的提交哈希就像身份证号——全球唯一，通过它你能精确定位到任何一个历史版本。

什么用：在AI项目中，每次调参、换模型、改数据都是一次提交。有了Git，你可以随时回到任何一个实验状态，对比不同参数的效果，而不是靠记忆或混乱的文件夹命名来管理实验。 哪些坑：①把大文件（数据集、模型权重）直接提交到Git仓库，导致仓库体积膨胀；②提交信息写"update"或"fix"，三个月后完全不知道改了什么；③在main分支上直接改代码，改坏了无法回退。

二、Git常用命令：init/add/commit/push/pull

是什么：Git的日常工作流就是一套固定节奏的命令：修改文件→暂存变更→提交快照→推送到远程→拉取他人更新。掌握这几个核心命令，就能覆盖90%的日常使用场景。

大白话：Git工作流就像寄快递——写好信（修改文件）→装进信封（git add）→贴邮票写地址（git commit）→投递（git push）→收别人的信（git pull）。每一步都不能跳过。

为什么：Git的三阶段设计（工作区→暂存区→仓库）让你可以精确控制哪些改动进入提交，而不是一股脑全提交。这在AI项目中尤其重要——你可能同时改了3个实验脚本，但只想提交其中1个。 怎么做：

import numpy as np

# ============================================
# Git 常用命令演示
# 用 numpy 模拟工作区→暂存区→仓库的三阶段流转
# ============================================

print("=" * 50)
print("🔧 Git 常用命令：日常工作流")
print("=" * 50)

# --- 模拟Git三阶段 ---
# 工作区(Working Directory) → 暂存区(Staging Area) → 仓库(Repository)

# 初始状态：仓库中已有文件
repo_files = np.array(["main.py", "utils.py", "config.yaml"])
print(f"\n📁 仓库中的文件: {repo_files}")

# 模拟：修改了 main.py 和 config.yaml
working_changes = np.array([1, 0, 1])  # 1=已修改, 0=未修改
print(f"✏️  工作区修改状态: {working_changes}")
print(f"   修改了: main.py, config.yaml")

# git add：将修改放入暂存区
# $ git add main.py config.yaml
# $ git add .              # 添加所有修改
staged_changes = np.array([1, 0, 1])  # 暂存区状态
print(f"\n📋 git add 后暂存区: {staged_changes}")
print(f"   已暂存: main.py, config.yaml")

# git status：查看当前状态
# $ git status
print("\n📊 git status 输出：")
print("  Changes to be committed:")
print("    modified:   main.py")
print("    modified:   config.yaml")

# git commit：将暂存区内容提交到仓库
# $ git commit -m "feat: 添加数据增强功能"
# 计算提交的变更量
change_magnitude = np.sum(staged_changes)  # 变更文件数
print(f"\n💾 git commit → 提交了 {change_magnitude} 个文件的变更")
print("   提交信息: 'feat: 添加数据增强功能'")

# git log：查看提交历史
# $ git log --oneline
print("\n📜 git log --oneline：")
print("  a1b2c3d feat: 添加数据增强功能 (HEAD -> main)")
print("  e4f5g6h fix: 修复数据加载bug")
print("  i7j8k9l init: 初始化项目")

# git push：推送到远程仓库
# $ git push origin main
print("\n🚀 git push origin main → 推送到GitHub远程仓库")

# git pull：拉取远程更新
# $ git pull origin main
print("\n⬇️  git pull origin main → 拉取远程最新代码并合并")

$$ \text{工作流} = \underbrace{\text{edit}}{\text{工作区}} \xrightarrow{\text{git add}} \underbrace{\text{stage}}{\text{暂存区}} \xrightarrow{\text{git commit}} \underbrace{\text{commit}}{\text{本地仓库}} \xrightarrow{\text{git push}} \underbrace{\text{remote}}{\text{远程仓库}} $$

大白话：暂存区就像购物车——你往里放东西（git add），但还没付款（git commit）。只有付了款，东西才真正属于你（进入仓库）。

什么用：在AI项目中，规范的提交流程让你能精确追踪每次实验的变更——改了哪些超参数、换了哪个数据集、调整了哪层网络结构。配合清晰的提交信息，三个月后你也能看懂当时为什么这样改。 哪些坑：①git add .把所有文件都加进去，包括临时文件和敏感信息；②git commit -m "update"提交信息太模糊；③忘记git pull就直接push，导致冲突；④把.env文件（含API密钥）提交到仓库。

三、分支与合并：branch/merge/rebase

是什么：分支是Git最强大的特性——它让你在不影响主线的情况下开发新功能、修复bug、做实验。合并（merge）和变基（rebase）是将分支成果合回主线的两种方式。

大白话：分支就像平行宇宙——你在实验宇宙里随便折腾，搞砸了也不影响现实宇宙。等实验成功了，再把成果合并回现实。merge和rebase是两种合并方式：merge保留历史痕迹，rebase让历史更整洁。

为什么：在AI项目中，你经常需要同时进行多个实验——尝试不同的模型架构、不同的超参数、不同的数据预处理方式。每个实验一个分支，互不干扰，实验成功就合并，失败就删除分支，干净利落。 怎么做：

import numpy as np

# ============================================
# Git 分支与合并演示
# 用 numpy 模拟分支创建、合并、冲突解决
# ============================================

print("=" * 50)
print("🌿 Git 分支与合并：并行开发的艺术")
print("=" * 50)

# --- 1. 分支创建与切换 ---
# 实际终端命令：
# $ git branch feature/cnn       # 创建分支
# $ git switch feature/cnn       # 切换到分支
# $ git switch -c feature/cnn    # 创建并切换（推荐）

print("\n【操作1】创建与切换分支")
print("  $ git switch -c feature/cnn-model")
print("  → 从main分支创建新分支feature/cnn-model")

# --- 2. 模拟分支上的开发 ---
# main分支的代码版本
main_code = np.array([1.0, 2.0, 3.0])  # 主分支：3个模块的版本号
print(f"\n📌 main分支代码版本: {main_code}")

# feature/cnn分支上修改了第2个模块
cnn_code = np.array([1.0, 2.5, 3.0])   # CNN分支：升级了模块2
print(f"📌 feature/cnn分支版本: {cnn_code}")

# feature/rnn分支上修改了第3个模块
rnn_code = np.array([1.0, 2.0, 3.5])   # RNN分支：升级了模块3
print(f"📌 feature/rnn分支版本: {rnn_code}")

# --- 3. 合并（Merge）---
# $ git merge feature/cnn-model
print("\n【操作2】合并分支到main")
print("  $ git switch main")
print("  $ git merge feature/cnn-model")

# 模拟合并：取两个分支的最大值（即采纳所有变更）
merged_code = np.maximum(main_code, cnn_code)
print(f"  合并后代码版本: {merged_code}")

# --- 4. 冲突检测与解决 ---
# 如果两个分支修改了同一行代码，就会产生冲突
print("\n【操作3】冲突检测与解决")

# 模拟冲突：两个分支都修改了模块2
conflict_branch_a = np.array([1.0, 2.5, 3.0])  # 分支A改了模块2
conflict_branch_b = np.array([1.0, 2.8, 3.0])  # 分支B也改了模块2

# 检测冲突位置
conflict_mask = (conflict_branch_a != conflict_branch_b) & \
                (conflict_branch_a != main_code) & \
                (conflict_branch_b != main_code)
conflict_indices = np.where(conflict_mask)[0]  # 冲突的模块索引

print(f"  分支A版本: {conflict_branch_a}")
print(f"  分支B版本: {conflict_branch_b}")
print(f"  冲突位置: 模块{conflict_indices + 1}（两个分支都修改了同一模块）")

# 手动解决冲突：选择版本2.8（分支B的方案更好）
resolved = conflict_branch_a.copy()       # 先复制分支A
resolved[conflict_indices] = 2.8          # 手动选择分支B的值
print(f"  冲突解决后: {resolved}（选择了分支B的模块2版本2.8）")

# --- 5. Merge vs Rebase ---
print("\n【操作4】Merge vs Rebase 对比")
comparison = np.array([
    ("git merge", "保留分支历史", "历史完整但复杂", "团队协作"),
    ("git rebase", "重写提交历史", "历史线性更整洁", "个人分支整理"),
], dtype=[("命令", "U15"), ("效果", "U15"), ("历史形态", "U20"), ("适用场景", "U15")])

for cmd, effect, shape, scene in comparison:
    print(f"  {cmd:<15} | {effect:<15} | {shape:<20} | {scene}")

$$ \text{Merge复杂度} = O(n + m), \quad n = \text{main提交数}, ; m = \text{分支提交数} $$

大白话：merge就像两个家族联姻——各自的家谱都保留，合并后家谱更庞大。rebase就像改姓——把你的家谱接到主家族后面，看起来像一直是一家人。

大白话：冲突就像两个人同时改了同一行代码——Git不知道听谁的，只能让你亲自拍板。解决冲突的核心原则：搞清楚两边的意图，选最合理的那个。

什么用：在AI项目中，分支策略是实验管理的核心。每个模型架构一个分支（feature/transformer、feature/lstm），每个超参数搜索一个分支（experiment/lr-search），实验完成就合并结果，失败就删除分支。GitHub Flow和Git Flow是两种主流分支策略。 哪些坑：①在共享分支上rebase，会改写他人依赖的提交历史，导致他人仓库混乱；②长期不合并的分支，冲突越积越多，最后合并时痛苦不堪；③删除分支前忘记合并，丢失实验成果。

四、GitHub协作流程：fork/clone/PR

是什么：GitHub是全球最大的代码托管平台，提供了fork（复制仓库）、clone（克隆到本地）、Pull Request（PR，合并请求）等协作机制，让全球开发者可以共同参与一个项目。

大白话：GitHub就像代码界的微信朋友圈——你看到别人的项目（仓库），可以收藏（fork一份到自己名下），可以下载（clone到本地），改好了可以发合并请求（PR），等原作者审核通过就合并进去。

为什么：开源AI项目（如PyTorch、Hugging Face Transformers）都托管在GitHub上。学会GitHub协作流程，你就能参与开源贡献、阅读顶级项目的代码、与全球AI开发者交流。这也是求职时展示能力的最佳平台。 怎么做：

import numpy as np

# ============================================
# GitHub 协作流程演示
# 用 numpy 模拟 fork/clone/PR 流程
# ============================================

print("=" * 50)
print("🌐 GitHub 协作流程：fork → clone → PR")
print("=" * 50)

# --- 1. Fork：复制仓库到自己名下 ---
# 在GitHub网页上点击"Fork"按钮
print("\n【步骤1】Fork — 复制仓库到自己名下")
print("  原仓库: aiqz-official/python-course")
print("  Fork后: your-name/python-course")
print("  → 你现在拥有了一份完全属于自己的副本，可以随意修改")

# --- 2. Clone：克隆到本地 ---
# $ git clone https://github.com/your-name/python-course.git
print("\n【步骤2】Clone — 克隆到本地开发")
print("  $ git clone https://github.com/your-name/python-course.git")
print("  $ cd python-course")

# --- 3. 创建分支并开发 ---
# $ git switch -c feature/add-data-augmentation
print("\n【步骤3】创建功能分支并开发")
print("  $ git switch -c feature/add-data-augmentation")
print("  → 在新分支上开发，不直接改main分支")

# --- 4. 提交并推送 ---
# $ git add .
# $ git commit -m "feat: 添加数据增强模块"
# $ git push origin feature/add-data-augmentation
print("\n【步骤4】提交并推送到你的Fork仓库")
print("  $ git add data_augmentation.py")
print("  $ git commit -m 'feat: 添加数据增强模块'")
print("  $ git push origin feature/add-data-augmentation")

# --- 5. 创建Pull Request ---
# 在GitHub网页上点击"New Pull Request"
print("\n【步骤5】创建Pull Request（PR）")
print("  在GitHub网页上：")
print("  1. 进入你的Fork仓库")
print("  2. 点击 'Contribute' → 'Open Pull Request'")
print("  3. 填写PR标题和描述（说明你做了什么、为什么做）")
print("  4. 等待项目维护者审核")

# --- 模拟PR审核流程 ---
print("\n📋 PR审核流程模拟：")

# 模拟代码变更的"审查分数"
pr_changes = np.array([
    ("data_augmentation.py", "+45/-0", "新增文件", "✅ 通过"),
    ("train.py", "+3/-1", "调用增强模块", "✅ 通过"),
    ("requirements.txt", "+1/-0", "添加依赖", "⚠️ 需讨论版本"),
], dtype=[("文件", "U25"), ("变更", "U10"), ("说明", "U20"), ("审核", "U15")])

for fname, change, desc, review in pr_changes:
    print(f"  {fname:<25} {change:<10} {desc:<20} {review}")

# --- 同步上游仓库 ---
print("\n🔄 同步上游仓库（保持Fork与原仓库同步）")
print("  $ git remote add upstream https://github.com/aiqz-official/python-course.git")
print("  $ git fetch upstream")
print("  $ git merge upstream/main")
print("  → 定期同步，避免你的Fork落后于原仓库")

$$ P(\text{PR被合并}) = f(\text{代码质量}, \text{测试覆盖}, \text{文档完整性}, \text{沟通态度}) $$

大白话：PR就像投稿——你写好文章（代码），提交给编辑部（项目维护者），编辑审核通过就发表（合并），不通过就退回修改。

什么用：在AI开源社区，几乎所有重要项目都通过PR接受贡献。Hugging Face、PyTorch、TensorFlow等项目的贡献流程都是fork→clone→改代码→提PR。学会这套流程，你就能给顶级AI项目贡献代码，这是简历上最有说服力的经历。 哪些坑：①Fork后长期不同步上游，导致你的代码和原项目差距越来越大；②PR描述写不清楚，维护者看不懂你改了什么；③一个PR改太多东西，审核困难；④不看项目的CONTRIBUTING.md就提PR，不符合项目规范。

五、AI项目中的版本控制实践：数据版本、模型版本、实验追踪

是什么：AI项目的版本控制不仅是代码版本，还包括数据版本（数据集变更）、模型版本（权重文件版本）、实验追踪（超参数+指标+代码的完整快照）。DVC（Data Version Control）和MLflow是AI领域常用的版本控制扩展工具。

大白话：AI项目的版本控制就像实验室的实验记录本——不仅要记录你做了什么（代码），还要记录用了什么材料（数据）、得到了什么结果（模型和指标）。光记代码不记数据，就像记了配方但忘了用了哪批原料。

为什么：AI实验的可复现性是最大的痛点——同样的代码换了数据集结果就不同，同样的超参数换了随机种子结果也不同。完整的版本控制（代码+数据+模型+配置）是可复现性的基础，也是AI工程化的前提。 怎么做：

import numpy as np

# ============================================
# AI 项目版本控制实践
# 用 numpy 模拟数据版本差异、模型版本管理、实验追踪
# ============================================

print("=" * 50)
print("🤖 AI项目版本控制：数据·模型·实验")
print("=" * 50)

# --- 1. 数据版本管理 ---
print("\n【实践1】数据版本管理")

# 模拟两个版本的数据集
data_v1 = np.array([1.2, 2.3, 3.1, 4.5, 5.0])   # 数据集v1
data_v2 = np.array([1.2, 2.3, 3.1, 4.5, 5.0, 6.2, 7.1])  # 数据集v2：增加了2条数据

# 计算数据差异
diff_count = len(data_v2) - len(data_v1)  # 新增数据条数
print(f"  数据集v1: {len(data_v1)}条, 均值={np.mean(data_v1):.2f}")
print(f"  数据集v2: {len(data_v2)}条, 均值={np.mean(data_v2):.2f}")
print(f"  变更: 新增{diff_count}条数据")

# 数据版本的最佳实践：用Git管理数据元信息，用DVC管理大文件
print("  实际做法: 用DVC跟踪数据文件，Git跟踪.dvc元文件")
print("  $ dvc add data/dataset.csv        # DVC跟踪数据")
print("  $ git add data/dataset.csv.dvc     # Git跟踪元文件")
print("  $ git commit -m 'data: 更新数据集v2'")

# --- 2. 模型版本管理 ---
print("\n【实践2】模型版本管理")

# 模拟不同版本模型的性能指标
model_versions = np.array([
    ("v1.0-baseline", 0.72, 0.68, 150),
    ("v1.1-tuned-lr", 0.78, 0.74, 150),
    ("v2.0-cnn", 0.85, 0.81, 300),
    ("v2.1-cnn-aug", 0.88, 0.84, 300),
], dtype=[("版本", "U20"), ("准确率", float), ("F1分数", float), ("参数量万", int)])

print(f"  {'版本':<20} {'准确率':>8} {'F1分数':>8} {'参数量(万)':>10}")
for row in model_versions:
    print(f"  {row['版本']:<20} {row['准确率']:>8.2f} {row['F1分数']:>8.2f} {row['参数量万']:>10}")

# 找出最佳模型
best_idx = np.argmax(model_versions["准确率"])  # 准确率最高的索引
print(f"  🏆 最佳模型: {model_versions[best_idx]['版本']} (准确率={model_versions[best_idx]['准确率']:.2f})")

# 模型版本管理建议
print("  实际做法: 用Git LFS或DVC管理模型权重文件")
print("  $ git lfs track '*.pt'            # Git LFS跟踪模型文件")
print("  $ git add .gitattributes")

# --- 3. 实验追踪 ---
print("\n【实践3】实验追踪（超参数+指标+代码版本）")

# 模拟实验记录
experiments = np.array([
    ("exp001", "a1b2c3d", 0.001, 32, 0.78),
    ("exp002", "e4f5g6h", 0.01, 64, 0.82),
    ("exp003", "i7j8k9l", 0.001, 64, 0.85),
    ("exp004", "m0n1o2p", 0.0001, 128, 0.88),
], dtype=[("实验ID", "U10"), ("代码版本", "U10"), ("学习率", float), ("批次大小", int), ("准确率", float)])

print(f"  {'实验ID':<10} {'代码版本':<10} {'学习率':>8} {'批次大小':>8} {'准确率':>8}")
for row in experiments:
    print(f"  {row['实验ID']:<10} {row['代码版本']:<10} {row['学习率']:>8.4f} {row['批次大小']:>8} {row['准确率']:>8.2f}")

# 找出最佳实验
best_exp = np.argmax(experiments["准确率"])  # 最佳实验索引
print(f"  🏆 最佳实验: {experiments[best_exp]['实验ID']} (准确率={experiments[best_exp]['准确率']:.2f})")
print(f"     可复现: git checkout {experiments[best_exp]['代码版本']}")

# 实验追踪工具推荐
print("\n  实验追踪工具推荐：")
print("  • MLflow: 开源实验追踪平台，记录参数+指标+模型")
print("  • Weights & Biases (W&B): 云端实验追踪，可视化强大")
print("  • DVC + Git: 本地化方案，数据+代码统一管理")

$$ \text{实验可复现性} = \text{代码版本} + \text{数据版本} + \text{超参数} + \text{随机种子} + \text{环境配置} $$

大白话：AI实验就像做菜——同样的菜谱（代码），换了食材（数据）味道就不同。版本控制就是确保你能精确还原每一次"做菜"的所有细节。

大白话：模型权重文件动辄几百MB到几GB，千万别直接用Git管理。用Git LFS或DVC，它们只存指针，大文件单独存储。

什么用：完整的版本控制体系让AI实验从"玄学调参"变成"科学实验"——每次实验都有完整记录，任何结果都可追溯、可复现。这是AI项目从研究走向工程化的必经之路，也是团队协作的基础。 哪些坑：①把GB级数据集和模型文件直接提交到Git，仓库瞬间膨胀到无法克隆；②不记录随机种子，同样的代码跑出不同结果无法复现；③实验记录只存在本地，电脑坏了全部丢失；④不区分实验代码和生产代码，导致线上模型无法回滚。

概念关系图谱

重点答疑

Q1：Git和GitHub是什么关系？初学者经常搞混。

Git是版本控制工具（软件），GitHub是代码托管平台（网站）。就像Git是录音机，GitHub是云盘——录音机负责录声音（记录版本），云盘负责存声音和分享（托管代码和协作）。你完全可以用Git而不用GitHub（代码只存本地），但用了GitHub就能云端备份和团队协作。类似的平台还有GitLab、Gitee（码云）。

Q2：什么时候用merge，什么时候用rebase？

简单原则：公共分支用merge，个人分支用rebase。公共分支（如main、develop）是多人共享的，rebase会改写提交历史，导致他人仓库混乱，所以必须用merge。个人分支（如你的feature分支）还没推送给别人，用rebase可以让历史更整洁线性。黄金法则：永远不要对已经推送到远程的分支执行rebase。

Q3：AI项目中的大文件（数据集、模型权重）怎么管理？

Git本身不适合管理大文件（超过100MB就会警告）。三种方案：①Git LFS（Large File Storage）：Git官方扩展，大文件单独存储，仓库中只保留指针文件；②DVC（Data Version Control）：专为AI项目设计，支持数据版本管理和模型版本管理；③云存储+元文件：大文件存到S3/OSS，Git只管理指向云存储的元文件。推荐DVC，它与Git深度集成，学习成本低。

Q4：如何写好Git提交信息？

推荐使用Conventional Commits规范：<类型>: <描述>。常见类型：feat（新功能）、fix（修复bug）、docs（文档）、refactor（重构）、test（测试）、chore（构建/工具）。例如：feat: 添加ResNet50模型训练脚本、fix: 修复数据加载时的索引越界问题、experiment: 尝试学习率0.001的Adam优化器。好的提交信息让git log像变更日志一样清晰可读。

Q5：AI项目中如何设计分支策略？

推荐GitHub Flow（简洁版）：main分支始终可部署，每个功能/实验从main拉分支，完成后提PR合并回main。对于更复杂的AI项目，可以用Git Flow：main（生产）+ develop（开发）+ feature/（功能）+ experiment/（实验）+ hotfix/*（紧急修复）。关键原则：main分支永远保持可运行状态，实验代码在独立分支上开发。

章节单词汇总