2、版本控制工具Git：Git基础概念、Git安装与配置、常用Git命令（clone、add、commit、push、pull）、分支管理策略

聊到MLOps，第一个绕不开的工具就是Git。说实话，我见过太多数据科学家把代码往U盘里一拷，或者用「最终版v3_改_真的不改了.py」这种命名方式。嗯，在单机实验阶段还能凑合，一旦进入团队协作、模型迭代、环境复现，这种习惯就是灾难。

Git说白了就是一个「时光机+协作平台」。它能记录你每一次修改，能让你在不同版本之间自由穿梭，还能让十几个人同时开发互不干扰。我刚开始带MLOps团队时，有个同事误删了训练好的模型权重文件，差点要重新跑三天。还好有Git，直接回退到上一个commit，五分钟解决问题。

2.1 Git基础概念

先搞清楚几个最核心的概念，不然后面命令会越学越乱。

• 仓库（Repository）：就是你的项目文件夹，但多了个隐藏的.git目录。这个目录里存着所有版本历史。
• 工作区（Working Directory）：你当前能看到的、正在编辑的文件。
• 暂存区（Staging Area）：一个中间缓冲区。你修改完文件后，先「add」到暂存区，再「commit」到仓库。为什么要多这一步？因为有时候你改了好几个文件，但只想把其中一部分提交上去。
• 提交（Commit）：一次快照。每次commit都会生成一个唯一的哈希值，相当于给当前状态拍了一张照片。
• 分支（Branch）：一条独立的开发线。默认是main或master分支，你可以创建新分支做实验，不影响主线。

我习惯把Git的工作流程想象成「拍照-选片-归档」。你在工作区修改文件，就像在拍照现场；git add是把满意的照片挑出来放到暂存区；git commit是把这些照片正式归档到相册里。每次归档都有一个唯一的编号，随时可以翻回去看。

2.2 Git安装与配置

安装Git很简单，去官网下载对应系统的安装包就行。Windows用户记得勾选「Git Bash」选项，这样能在Windows上模拟Linux命令行环境。

装完之后，第一件事是配置你的身份信息。为什么？因为每次commit都会记录作者是谁。我见过有人用「test123」这种用户名提交代码，后面出了问题根本找不到人。

# 配置用户名和邮箱（全局配置）
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

# 查看配置是否生效
git config --list

# 如果你有多个项目需要不同身份，可以去掉 --global，在项目目录内单独配置
git config user.name "项目专用名字"

还有一个配置我强烈建议加上：

# 让Git自动处理换行符问题（Windows和Mac/Linux的换行符不一样）
git config --global core.autocrlf true   # Windows用户
git config --global core.autocrlf input  # Mac/Linux用户

2.3 常用Git命令

说实话，Git的命令有上百个，但日常工作中80%的场景只需要下面这几个。我按使用频率排序讲。

2.3.1 git clone —— 把远程仓库复制到本地

这是你接触一个项目的第一步。比如你在GitHub上看到一个MLOps项目，想下载到本地研究：

git clone https://github.com/用户名/仓库名.git
# 或者用SSH方式（需要提前配置SSH密钥）
git clone git@github.com:用户名/仓库名.git

克隆完成后，本地会多出一个和仓库同名的文件夹，里面包含了完整的版本历史。你可以用git log查看所有历史commit。

2.3.2 git add —— 把修改放到暂存区

你修改了文件后，Git不会自动追踪这些修改。你需要手动告诉Git：「嘿，这些改动我要提交」。git add就是干这个的。

# 添加单个文件
git add train.py

# 添加当前目录所有修改（慎用，容易把不该提交的文件加进去）
git add .

# 添加所有 .py 文件
git add *.py

# 查看当前哪些文件被修改了、哪些在暂存区
git status

我个人习惯用git add -p，这个命令会逐块显示你的修改，让你选择是否添加到暂存区。对于大型文件修改，这个命令能帮你精细控制提交内容。

2.3.3 git commit —— 创建一次快照

暂存区准备好了，就可以正式提交了。每次commit都需要写一条消息，说明这次改了什么。

# 提交并写消息
git commit -m "修复数据加载时的内存泄漏问题"

# 如果忘记写 -m，会进入vim编辑器让你写多行消息
git commit

关于commit消息的写法，我建议遵循「动词+具体内容」的格式。比如「添加特征工程模块」、「修复验证集划分bug」、「更新模型超参数」。不要写「修改了一些东西」这种毫无信息量的消息。

2.3.4 git push —— 把本地commit推送到远程

本地commit完成后，如果想分享给团队或备份到GitHub，就需要push。

# 推送到远程仓库的当前分支
git push origin main

# 如果远程仓库有新的commit，push会被拒绝。你需要先pull再push
git pull origin main
git push origin main

这里有个常见的坑：git push之前一定要先git pull。我见过有人直接push，结果覆盖了同事的代码，差点引发血案。记住一个原则：先pull，再push，永远不要强制推送（--force）。

2.3.5 git pull —— 拉取远程的最新代码

团队协作时，别人可能在你之前推送了代码。你需要先把这些代码拉下来，合并到本地，再推送你的修改。

# 拉取远程仓库的最新代码并自动合并
git pull origin main

# 如果只想拉取但不自动合并，可以用 fetch
git fetch origin
git merge origin/main

git pull其实是git fetch + git merge的组合命令。我个人习惯用git fetch先看看远程有什么变化，确认没问题后再手动合并。这样更安全。

2.4 分支管理策略

分支是Git最强大的功能之一。没有分支管理，多人协作就是一场噩梦。你想想看，如果所有人都直接在main分支上开发，A改了一行代码，B也改了一行，两个人同时push，冲突会多到让你崩溃。

分支的本质是什么？就是一条独立的开发线。你在自己的分支上随便改，不影响别人。等开发完成、测试通过后，再合并回主分支。

2.4.1 分支的创建与切换

# 创建新分支
git branch feature/data-pipeline

# 切换到新分支
git checkout feature/data-pipeline

# 创建并切换一步到位（我常用这个）
git checkout -b feature/data-pipeline

# 查看所有分支（当前分支前面有个 *）
git branch

# 删除分支（合并后才能删除）
git branch -d feature/data-pipeline

2.4.2 合并分支

开发完成后，需要把功能分支合并回主分支。有两种合并方式：

# 方式一：直接合并（会保留所有commit历史）
git checkout main
git merge feature/data-pipeline

# 方式二：压缩合并（把多个commit压缩成一个，历史更干净）
git merge --squash feature/data-pipeline
git commit -m "添加数据管道功能"

我个人更推荐压缩合并。为什么？因为开发过程中的commit往往很杂乱，比如「改了个typo」、「又改了个typo」、「测试一下」、「再测试一下」。这些commit对主线没有意义，压缩成一个干净的commit，历史看起来更清爽。

2.4.3 常见的分支策略

在MLOps项目中，我推荐使用Git Flow的简化版：

分支类型	命名规则	用途
主分支	main	生产环境代码，必须经过严格测试和review才能合并
开发分支	develop	日常开发的主线，所有功能分支从这里拉出
功能分支	feature/xxx	开发新功能，比如feature/数据预处理
修复分支	hotfix/xxx	紧急修复生产环境bug，直接从main拉出
实验分支	experiment/xxx	尝试新想法，比如experiment/尝试新模型结构

这个策略的好处是：main分支永远保持可部署状态，develop分支是日常开发集散地，功能分支各自独立开发。出了问题，最多影响一个功能分支，不会波及整个项目。

2.5 本章知识体系

下面这张图总结了Git在MLOps中的核心工作流。你可以把它当作一个快速参考。

这张图展示了Git在MLOps中的完整工作流。从左到右是本地操作（工作区→暂存区→本地仓库），从上到下是远程同步（push/pull），底部是分支管理策略。记住这个流程，你就能应对90%的日常场景。

---

公众号:蓝海资料掘金营，微信deep3321