2、Git核心操作与风控代码仓库搭建
聊到版本控制，我见过不少团队还在用「复制粘贴+日期命名」的方式管理代码。说实话，这在风控系统里简直是灾难。你想想看，一个规则引擎的配置文件改错了，回滚都不知道回滚到哪一版。
这一章，我们就来搞定 Git 的安装配置、仓库初始化，以及风控场景下最实用的分支策略。我会结合我在金融风控项目中的实际踩坑经历，帮你把仓库结构搭得明明白白。
2.1 Git 安装与基础配置
安装 Git 本身没什么难度，但配置这一步很多人会忽略。我建议你从一开始就做好三件事：
- 设置全局用户名和邮箱 —— 这关系到提交记录的归属，别用「admin」这种名字
- 配置 SSH 密钥 —— 风控代码通常敏感，HTTPS 每次输密码太麻烦也不安全
- 开启颜色显示 —— 嗯，这个小习惯能让你在 diff 时少看花眼
我的个人习惯配置：
git config --global user.name "Your Name"
git config --global user.email "your.email@company.com"
git config --global color.ui auto
git config --global core.autocrlf input # 避免换行符问题小提示： 在风控团队里，我建议把 user.email 统一为公司邮箱。曾经有个同事用了个人邮箱提交，审计时差点被当成外部入侵。
2.2 仓库初始化：从零开始搭风控代码库
初始化一个仓库很简单，但怎么组织目录结构才是关键。我见过最糟糕的情况是：所有规则脚本、模型文件、配置文件全扔在根目录下。结果上线时，运维小哥根本分不清哪个是生产用的。
我的做法是：先想清楚风控系统有哪些模块，再动手建目录。一般来说，风控代码仓库至少需要这几个部分：
- 规则引擎 —— 存放决策树、规则集、评分卡
- 模型服务 —— 模型文件、特征工程脚本
- 配置中心 —— 阈值、白名单、渠道参数
- 测试与模拟 —— 回测数据、压测脚本
- 部署脚本 —— Dockerfile、K8s 配置、CI/CD 流水线
推荐的风控仓库目录结构：
risk-control-system/
├── rules/ # 规则引擎
│ ├── decision-trees/
│ ├── scorecards/
│ └── rule-sets/
├── models/ # 模型服务
│ ├── feature-engineering/
│ └── model-files/
├── config/ # 配置中心
│ ├── thresholds.yaml
│ ├── whitelist.yaml
│ └── channel-params.yaml
├── tests/ # 测试与模拟
│ ├── backtest/
│ └── stress-test/
├── deploy/ # 部署相关
│ ├── docker/
│ └── k8s/
├── docs/ # 文档
└── .gitignore避坑指南： 我曾经把一个包含生产数据库连接信息的配置文件直接提交到了 Git 仓库。还好发现得早，否则后果不堪设想。记住：敏感信息永远不要提交到代码库，用环境变量或密钥管理服务。
2.3 分支管理策略：Git Flow vs Trunk Based
分支策略这东西，没有绝对的好坏，只有合不合适。我在风控项目里两种都用过，说说我的感受。
Git Flow：适合大型、多版本并行的风控系统
Git Flow 有 master、develop、feature、release、hotfix 五种分支。听起来复杂，但好处是隔离性强。比如线上有个紧急漏洞，你可以在 hotfix 分支上修，不影响正在开发的 feature。
我曾在某银行的风控项目中用过 Git Flow。当时我们同时维护着三个版本：一个线上稳定版、一个灰度测试版、一个下季度的大版本。Git Flow 的分支模型帮我们理清了这些版本的边界。
Trunk Based：适合快速迭代、持续交付的团队
Trunk Based 就简单多了：所有人都在 main 分支上开发，通过特性开关控制功能是否上线。它的核心思想是「小步快跑，频繁合并」。
说实话，我现在更倾向于 Trunk Based。为什么？因为风控系统需要快速响应业务变化。比如双十一大促，规则可能一天改三次。如果用 Git Flow，光合并分支就能把人搞疯。
| 对比维度 | Git Flow | Trunk Based |
|---|---|---|
| 分支数量 | 多（5种以上） | 少（1-2种） |
| 合并复杂度 | 高 | 低 |
| 适合场景 | 多版本并行、发布周期长 | 快速迭代、持续交付 |
| 风控适用性 | 银行、保险等强监管行业 | 互联网、电商等高频变化场景 |
我的建议： 如果你的风控系统需要频繁调整规则（比如每天都有新策略），选 Trunk Based。如果你们有严格的审计和版本追溯要求（比如金融监管），Git Flow 更稳妥。
2.4 风控代码仓库目录结构设计（核心）
目录结构设计得好，团队协作效率能提升一大截。我总结了一套「三层分离」的原则：
- 第一层：按功能模块分 —— 规则、模型、配置、测试、部署
- 第二层：按环境分 —— dev、staging、prod 的配置分开存放
- 第三层：按版本分 —— 每个版本的规则集或模型文件独立目录
举个例子，规则引擎的目录可以这样设计：
rules/
├── v1.0/
│ ├── fraud-detection.yaml
│ └── credit-scoring.yaml
├── v1.1/
│ ├── fraud-detection.yaml
│ └── credit-scoring.yaml
└── current/ # 指向当前生产版本
└── (symlink to v1.1)为什么要这么做？因为风控规则的回滚是家常便饭。如果某个版本上线后误杀率飙升，你需要在 5 分钟内切回旧版本。用目录版本管理，直接改个软链接就搞定了。
核心原则总结：
- 配置与代码分离 —— 配置文件不要硬编码在代码里
- 环境与版本分离 —— 不同环境用不同的配置文件
- 敏感信息零提交 —— 密钥、密码永远不进 Git
- 目录扁平化 —— 嵌套不超过 3 层，否则找文件累死人
2.5 本章知识体系总览
下面这张图是我手绘的，把本章的核心逻辑串起来了。你可以把它当作一个「思维导图」来理解：
嗯，这张图基本把本章的核心逻辑讲清楚了。从安装配置开始，到仓库初始化，再到分支策略和目录结构设计，最后落到最佳实践和避坑指南。你可以在实际搭建仓库时，对照这张图一步步来。
最后说一句： 仓库结构不是一成不变的。随着业务发展，你可能需要调整目录或分支策略。关键是保持「可追溯、可回滚、可协作」这三个核心目标。其他的，都是手段。