3、Git在模型管理中的应用：Git LFS大文件存储、Git子模块管理模型仓库、Git标签与分支策略

模型管理这件事，说白了就是管好「谁在什么时候改了什么东西」。我见过太多团队，模型文件散落在各个同事的硬盘里，版本号靠文件名里的「最终版」「最终版2」「打死不改版」来区分。嗯，这其实是个灾难。

Git 本身是给代码设计的，模型文件动辄几百 MB 甚至 GB 级别，直接往里塞肯定不行。但 Git 的生态里，有几个工具能帮我们解决这个问题。我个人习惯用 Git LFS 管大文件，用子模块管多模型仓库，再用标签和分支策略来规范迭代流程。下面一个一个说。

3.1 Git LFS：大模型文件怎么存

Git 默认会把每个文件的完整历史都存下来。你想想看，一个 500MB 的模型文件，改 10 次版本，仓库体积就奔着 5GB 去了。克隆一次，等半天。这谁受得了？

Git LFS（Large File Storage）的思路很简单：把大文件替换成指针文件，真正的文件内容存到远程服务器上。本地只保留你当前需要的那一份。

安装和配置也很直接：

# 安装 Git LFS
git lfs install

# 在仓库里指定哪些文件类型用 LFS 管理
git lfs track "*.pt"
git lfs track "*.h5"
git lfs track "*.onnx"

# 别忘了提交 .gitattributes 文件
git add .gitattributes
git commit -m "配置 LFS 跟踪规则"

我在项目中遇到过一个问题：有同事忘了执行 git lfs install，结果直接把大文件当普通文件提交了。仓库瞬间膨胀到 2GB，推都推不上去。后来我们规定，新成员加入项目的第一步就是跑 git lfs install，并且在 CI 里加了检查脚本。

3.2 Git 子模块：多模型仓库怎么组织

一个完整的 AI 项目，往往包含多个模型。比如一个目标检测系统，可能有检测模型、分类模型、后处理模型。如果全塞在一个仓库里，体积爆炸不说，不同模型的迭代节奏也不一样。

Git 子模块（Submodule）能解决这个问题。它允许你在主仓库里引用另一个独立的 Git 仓库。说白了，就是「仓库里套仓库」。

举个例子：

# 添加一个子模块
git submodule add https://github.com/your-team/detection-model.git models/detection

# 克隆包含子模块的项目（带 --recursive）
git clone --recursive https://github.com/your-team/main-project.git

# 更新子模块到最新版本
git submodule update --remote models/detection

这里有个坑，我踩过好几次：子模块默认处于「分离头指针」状态。什么意思呢？就是你在子模块里改了代码，如果不先切到分支再提交，这些修改很容易丢失。我曾经因为这个丢过一整天的实验记录，后来养成了习惯——进子模块先 git checkout main。

我个人建议的目录结构是这样的：

project-root/
├── models/                  # 子模块统一放这里
│   ├── detection/           # 检测模型（独立仓库）
│   ├── classification/      # 分类模型（独立仓库）
│   └── postprocess/         # 后处理模型（独立仓库）
├── code/                    # 主项目代码
├── data/                    # 数据（通常用 LFS 或单独管理）
└── .gitmodules              # 子模块配置文件

3.3 Git 标签与分支策略：版本怎么管

模型迭代和软件迭代不太一样。软件迭代可以每天发版，但模型迭代往往需要长时间训练、验证、对比。所以分支和标签的策略，要围绕「实验」和「发布」两个场景来设计。

分支策略：实验分支 + 稳定分支

我习惯用这样的分支结构：

• main：稳定分支，只合入经过验证的模型。每次合入都对应一个可发布的版本。
• experiment/xxx：实验分支，比如 experiment/loss-v2、experiment/backbone-resnet50。这些分支可以随便改，失败了直接删掉。
• release/x.y.z：发布分支，用于最终测试和部署。比如 release/1.0.0。

举个例子，你有个新想法想试试：

# 从 main 切出实验分支
git checkout -b experiment/backbone-swin

# 训练、调参、提交
git add .
git commit -m "实验：替换 backbone 为 Swin-Tiny"

# 验证通过后，合并到 main
git checkout main
git merge experiment/backbone-swin

# 打标签发布
git tag -a v1.2.0 -m "发布 v1.2.0：Swin-Tiny backbone，mAP 提升 2.3%"

标签策略：语义化版本 + 模型指标

标签是 Git 里最容易被忽视的功能。很多人只用分支，不用标签。但标签才是「快照」的正确打开方式。我建议用语义化版本号，同时在标签信息里记录关键指标：

# 轻量标签（只记录版本号）
git tag v1.0.0

# 附注标签（推荐，可以写详细说明）
git tag -a v1.0.0 -m "版本 1.0.0
- 模型：YOLOv8s
- 精度：mAP 0.523
- 训练数据：COCO 2017
- 备注：首次发布"

标签和分支配合起来，能形成清晰的版本追溯链。比如你发现 v1.2.0 的模型在某个场景下有问题，可以快速切到那个标签，复现问题，然后从那个节点拉出修复分支。

# 查看所有标签
git tag -l "v1.*"

# 切到某个历史版本
git checkout v1.2.0

# 从历史版本拉修复分支
git checkout -b fix/v1.2.0-hotfix

3.4 实战建议：一个完整的模型仓库配置

最后，我分享一个我目前在用的仓库初始化流程。你可以直接拿来用：

# 1. 初始化仓库
git init
git lfs install

# 2. 配置 LFS 跟踪
git lfs track "*.pt"
git lfs track "*.h5"
git lfs track "*.pth"
git lfs track "*.onnx"
git lfs track "*.bin"

# 3. 添加子模块（如果有多个模型）
git submodule add https://github.com/team/detection-model.git models/detection

# 4. 创建 .gitignore
echo "*.log
__pycache__/
data/raw/
experiments/" > .gitignore

# 5. 首次提交
git add .
git commit -m "初始化模型仓库"

# 6. 打初始标签
git tag -a v0.1.0 -m "初始版本：项目框架搭建完成"

嗯，Git 在模型管理中的应用，核心就是这三板斧：LFS 管大文件、子模块管多仓库、标签和分支管版本。把这套流程跑顺了，模型迭代就不再是「玄学」，而是可追溯、可复现的工程实践。