Git企业级实践：多仓库管理、代码审查流程、发布管理、版本号规范
说实话，很多团队用Git只是把它当个网盘用——push、pull、完事。但真正到了企业级项目里，你会发现事情远没那么简单。多仓库怎么协调？代码审查怎么落地？发布流程怎么自动化？版本号怎么定才不乱？
我在几家不同规模的公司都待过，踩过不少坑。今天就把这些经验掰开揉碎，跟你聊聊。
一、多仓库管理：别让项目变成一团乱麻
一个大型项目，往往拆成十几个甚至几十个仓库。前端一个、后端一个、公共库一个、配置文件一个……怎么管？
我个人的习惯是：用repo工具或者Git Submodule来统一管理。但Submodule有个坑——它只记录一个固定的commit，你更新了子仓库，主仓库还得手动更新引用。
更好的方案是用Git Subtree或者Monorepo。Subtree把子仓库的代码直接合并到主仓库里，操作起来更直观。Monorepo则是把所有代码放一个仓库，用目录隔离——Google、微软都这么干。
二、代码审查流程：不只是走个过场
代码审查（Code Review）在很多团队里变成了形式主义——点个“Approved”就完事。但真正有效的审查，应该像一场技术对话。
我建议的流程是这样的：
- 开发者创建Pull Request（PR），描述清楚改了啥、为什么改、怎么测试的。
- 至少2个Reviewer。一个负责业务逻辑，一个负责代码质量。
- Reviewer逐行评论，不只是“LGTM”。要问“这里为什么用map不用for？”“这个异常处理是不是漏了？”
- 开发者回复并修改，直到所有评论都解决。
- CI通过后，才能合并。合并策略推荐“Squash and Merge”，保持主分支历史干净。
我曾经在一个项目里，因为审查太松，把一个有性能隐患的代码合并到了主分支。上线后数据库连接池被打爆，紧急回滚。从那以后，我定了个规矩：任何PR必须经过至少一个资深工程师的审查，且CI必须全绿。
三、发布管理：从开发到上线，每一步都要可控
发布管理说白了就是：你怎么保证你push的代码，不会把线上搞崩？
我常用的分支模型是这样的：
- main：只放稳定版本。每次合并都打tag。
- develop：日常开发分支。所有feature分支从这里拉。
- feature/xxx：每个新功能一个分支，开发完合并到develop。
- release/x.x.x：从develop拉出来，只修bug，不加新功能。测试通过后合并到main和develop。
- hotfix/x.x.x：线上紧急bug，从main拉，修完合并回main和develop。
这个模型叫Git Flow，虽然有点重，但对于需要严格版本管理的企业项目来说，非常稳。
git log --oneline --no-merges main..release/1.0.0看看这次发布了哪些commit。我习惯把这个日志贴到发布公告里，方便回溯。
四、版本号规范：语义化版本（SemVer）
版本号不是随便写的。我见过有人从1.0.0直接跳到2.0.0，就因为“改了个大功能”。这其实不对。
语义化版本（SemVer）的规则很简单：
| 格式 | 含义 | 举例 |
|---|---|---|
MAJOR.MINOR.PATCH |
主版本.次版本.补丁版本 | 1.2.3 |
| MAJOR | 不兼容的API修改 | 2.0.0 |
| MINOR | 向下兼容的新功能 | 1.3.0 |
| PATCH | 向下兼容的bug修复 | 1.2.4 |
举个例子：你修复了一个登录页面的样式bug，版本号从1.2.3升到1.2.4。你加了一个新的API接口，但没改旧的，版本号升到1.3.0。你改了数据库表结构，旧版本不兼容了，版本号升到2.0.0。
1.0.0有bug，应该发布1.0.1，而不是重新打1.0.0的tag。我见过有人这么干，结果同事本地缓存了旧版本，排查了半天。
五、知识体系总览
下面这张图，把上面讲的内容串起来了。你可以把它当成一个速查表：
你看，这四个方面其实是环环相扣的。多仓库管不好，代码审查就乱；审查不严，发布就提心吊胆；版本号不规范，回滚都不知道该回哪个版本。
嗯，今天就聊到这儿。这些实践不是一天建成的，你可以先从版本号规范开始，再逐步引入分支模型和审查流程。慢慢来，比较快。