3、Git版本控制：Git安装与配置、仓库初始化、分支管理策略、代码回滚
聊到量化套利系统的部署，版本控制是绕不开的一环。说实话，我见过不少团队，代码写得挺漂亮，但一上线就乱成一锅粥——有人改了配置文件没通知，有人直接在生产环境改代码，还有人回滚时把别人的提交给覆盖了。嗯，这些坑我都踩过。
Git 这东西，说白了就是给代码上了一道保险。你想想看，没有版本控制，你改完代码发现跑不通了，想回去都找不到路。有了 Git，你随时可以「时光倒流」。今天我就把我在量化运维中积累的 Git 实战经验，掰开了揉碎了讲给你听。
核心要点：Git 不是用来「存代码」的，而是用来「管流程」的。量化套利系统的代码变更频繁，一个分支策略没设计好，上线时就是灾难。
3.1 Git 安装与配置
先说说安装。我个人习惯在 Linux 服务器上直接装 Git，因为我们的套利系统跑在 CentOS 或 Ubuntu 上。命令很简单：
# Ubuntu / Debian
sudo apt-get update
sudo apt-get install git -y
# CentOS / RHEL
sudo yum install git -y
# 验证安装
git --version装完之后，第一件事就是配置用户信息。这一步很多人会跳过，但我在项目中吃过亏——有一次排查线上问题，发现提交记录里全是「unknown」，根本不知道是谁改的。所以，请务必执行：
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"还有几个配置我建议你顺手设好：
- 别名配置：我习惯把常用命令设成短别名，比如
git co代替git checkout - 默认编辑器：设成 vim 或 nano，别用默认的 vi（新手容易卡住）
- 换行符处理：量化团队经常跨 Windows 和 Linux 开发，建议设
core.autocrlf input
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global core.editor "vim"
git config --global core.autocrlf input我的小技巧：配置完成后，用 git config --list 检查一遍。我曾经因为拼写错误，把邮箱写成了「@gmial.com」，结果同事的 PR 一直收不到通知，排查了半天才发现。
3.2 仓库初始化
初始化仓库有两种场景：一种是全新项目，一种是克隆已有项目。
场景一：从零开始
假设我们要为套利系统新建一个项目，目录结构大概是这样的：
arbitrage-system/
├── config/
│ ├── trading.conf
│ └── risk.conf
├── src/
│ ├── strategy/
│ ├── execution/
│ └── monitor/
├── scripts/
│ └── deploy.sh
└── README.md初始化命令很简单：
cd arbitrage-system
git init
git add .
git commit -m "feat: 初始化套利系统项目结构"这里有个细节要注意——.gitignore 文件。量化系统里有很多敏感文件，比如 API 密钥、日志文件、临时数据，这些绝对不能提交到仓库。我见过有人把交易所的 API Key 直接提交到 GitHub 上，结果几分钟内账户就被盗了。所以，初始化后第一件事就是写好 .gitignore：
# .gitignore 示例
*.log
*.key
config/*.secret
__pycache__/
*.pyc
.env
data/raw/场景二：克隆已有项目
如果是加入现有团队，直接克隆就好：
git clone git@github.com:your-team/arbitrage-system.git
cd arbitrage-system注意：克隆时建议用 SSH 协议而不是 HTTPS。HTTPS 每次推送都要输密码，很烦。配置好 SSH Key 后，一劳永逸。
3.3 分支管理策略
分支管理是 Git 的灵魂。量化套利系统的特点是：策略迭代快、风险敏感度高、需要快速回滚。所以分支策略必须兼顾灵活性和稳定性。
我个人在多个量化项目中实践下来，推荐这套策略：
| 分支名称 | 用途 | 谁可以合并 | 生命周期 |
|---|---|---|---|
main |
生产环境代码，稳定可用 | 仅运维负责人 | 永久 |
develop |
开发主分支，集成测试 | 开发团队 | 永久 |
feature/* |
新策略开发 | 个人开发者 | 短期，开发完即删除 |
release/* |
发布前准备，只修 bug | 运维团队 | 短期，发布后合并到 main 和 develop |
hotfix/* |
生产环境紧急修复 | 运维负责人 | 极短期，修复完即删除 |
为什么这么设计？我举个例子。有一次我们的套利策略在凌晨突然出现异常，收益率曲线直线下降。当时如果走正常的 feature 分支开发流程，等测试完再上线，黄花菜都凉了。所以我们直接从 main 分支拉了一个 hotfix/urgent-fix 分支，修完 bug 后直接合并回 main 和 develop。整个过程不到 20 分钟。
实际操作中，分支操作是这样的：
# 创建 feature 分支
git checkout -b feature/new-arbitrage-strategy develop
# 开发完成后合并到 develop
git checkout develop
git merge --no-ff feature/new-arbitrage-strategy
git branch -d feature/new-arbitrage-strategy
# 创建 release 分支
git checkout -b release/v1.2.0 develop
# 修复 release 分支上的 bug 后，合并到 main 和 develop
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0
git branch -d release/v1.2.0关键点：合并时一定要用 --no-ff 参数。这样能保留分支的历史记录，方便以后排查问题。我曾经因为没用这个参数，结果回滚时根本分不清哪些提交是 feature 分支的，差点把别人的代码也回滚了。
3.4 代码回滚
回滚是运维的保命技能。量化系统上线后，万一新策略出了问题，你必须能在 1 分钟内回到上一个稳定版本。
Git 提供了三种回滚方式，我按使用频率排序：
- git revert：最安全的方式，会生成一个新的提交来「撤销」之前的提交。适合已经推送到远程仓库的情况。
- git reset：直接删除提交历史，适合本地分支或未推送的提交。
- git checkout：切换到某个历史版本查看，但不修改分支指针。
实战中，我最常用的是 git revert。为什么呢？因为量化系统是多人协作的，你直接 git reset 会破坏别人的提交历史，到时候大家一拉代码就冲突，场面会很尴尬。
举个例子：假设我们发布了 v1.2.0，但发现有个 bug 导致套利信号延迟了 3 秒。我们需要回滚到 v1.1.0：
# 查看提交历史
git log --oneline --graph
# 找到 v1.1.0 的 commit hash，假设是 a1b2c3d
git revert a1b2c3d..HEAD --no-commit
# 确认无误后提交
git commit -m "revert: 回滚到 v1.1.0，修复信号延迟问题"
# 推送到远程
git push origin main这里有个小技巧——git revert 可以一次回滚多个提交，用 .. 指定范围就行。但要注意，如果中间有合并提交，可能会产生冲突。我建议你回滚前先 git log 看清楚提交图。
我曾经踩过的坑：有一次我直接用 git reset --hard HEAD~3 回滚了 3 个提交，然后 git push --force 推了上去。结果同事的本地分支还在基于那 3 个提交开发，一拉代码直接乱掉。从那以后，只要代码已经推送到远程，我绝不用 git reset。
还有一个场景——回滚配置文件。量化系统的配置文件经常被修改，比如调整交易对、修改费率参数。如果改错了，可以用 git checkout 恢复单个文件：
# 恢复 config/trading.conf 到上一个版本
git checkout HEAD~1 -- config/trading.conf
# 或者恢复到某个特定版本
git checkout a1b2c3d -- config/trading.conf我的习惯：每次修改配置文件前，先 git stash 保存当前工作区，然后拉取最新代码，再 git stash pop 恢复。这样能避免不小心把未完成的修改提交上去。
知识体系总览
下面这张图是我自己画的 Git 版本控制知识体系，涵盖了从安装到回滚的完整流程。你可以把它当作一个快速索引：
Git 这东西，用熟了就是肌肉记忆。但刚开始的时候，我建议你多敲几遍命令，尤其是回滚操作。找个测试仓库，故意制造几个冲突，然后练习解决。等你真正上线时，就不会手忙脚乱了。